I know. Doesn't change the fact there exist no sensible way to backup a decently sized pool in a home-user scenario.
Now we might disagree on what is sensible. And some things might not need a backup.
In home scenarios, you usually care about documents, pictures a few specific videos and some music above everything else. This tends to be a fraction of the total capacity. The rest doesn't change very often and is not such a loss but tends to be quite huge in comparison. So to backup all documents and pictures one or two external drives and/ or a cloud backup is sufficient.
Personally, for some important documents I use orgpad.com which I help build. I am personally responsible for the infrastructure - so the backups actually have at least three tiers, independent providers etc. That is just a side effect of having a SaaS platform with a reasonable and contactable team behind it.
Targets:
1. That NAS off in the corner built from an old desktop.
2. rsync.net and similar.
3. your encrypted cloud backup service of choice, through an adapter.
If the value of your data is less than the cost to protect it, you know it is disposable, you just wish it weren't.
These 2 solutions cost less than 10 USD/month: Jottacloud [1] and zfs.rent [2]. The former is even hosted in privacy-friendly Norway, and its 5 TB unlimited with going over that you get upload-capped. So I pay 90 EUR/year for Jottacloud. Which is approx 10% of your projected 1000 USD.
zfs.rent is an interesting model, though quite beta and currently not accepting users. And those prices add up pretty fast. Let's say you want to back up about 4 drives of data. That's $960 a year for the first two years, then $480 a year after. Or if you want any redundancy at all, $1200/$600. You'd probably want to find your own cheaper box to stuff hard drives into, and at that point you're far gone from "cloud".
2. You can build a 8TBx4+2 raidz2 with EasyStores for $720. Backing that up to a raidz1 zfs.rent is $1200 for a single year. $2500 for 3 years by prepurchasing the drives.
An estimate of $1000/year for full cloud backups isn't wrong.
If I had an amount of 24 TB to back up I'd buy my own server and harddisks, and I'd physically set that server up at work or at home. Then, travel to the data center (I live in Amsterdam Area, so enough choice) and put the server there, again, physically. No need to "upload 24 TB".
RAIDZ et al. is about availability. Which makes sense for businesses, but for personal data an offsite backup makes more sense. I'd just go with a mirror of 2 different disks, with different serial numbers (ie. different orders).
But using that pricing, 24TB with Jottacloud would be 450 EUR/year, which is still on the order of $1000. The larger point is that disk sizes are always growing, and while 24TB may seem unnecessary to you, it's very easy to build an array that is cumbersome to backup. And IME this has remained true for the past two decades.
You're right that the cost effective way of performing large backups seems to be just buying another array and hosting it somewhere offsite. But that still doubles your array cost, and so is not something to be done lightly.
FWIW personal users want availability too, unless rebuilding arrays from scratch is your hobby. A simple mirror is a form a raid, which you can only get away with if your storage requirements can be taken care of by a single spindle. If that's where you are, fantastic. But that doesn't describe most home ZFS users.
So for 24TB you would use two accounts, assuming they're fine with that, and your uploads would run at 5Mbps per thread, with 12 threads in parallel.
That will let you upload 100GB every 4 hours, which should be enough. And the total cost would be 180EUR/year, which is pretty far from $1000.
https://www.cloudwards.net/backblaze-pricing/
It does sound good. :)
Its also just the first backup which takes a (long) while. If you got only 10 mbit upload, then you're able to upload 600 mbit per minute, or 36000 mbit per hour. Which is about 4500 mB/hour (or ~4,4 GB/hour). Which results in 108000 mB/day (or ~105 GB/day). Its about 3/4 of a TB a week.
I'm glad I got 30+ mbit upload with my VDSL2. My first backups took ages (I got 5 TB with Jottacloud). First I thought it was Duplicati being slow with regards to cryptography or being .NET, but nope that ain't it.
Incremental backups during night are not going to hamper the connection though.
That's best case. Anyone who's done large transfers over the internet knows reality will be much worse.
The point is that home users can have good reasons for relying on redundancy.
https://www.backblaze.com/b2/cloud-storage-pricing.html
I only have a few TB, but the setup cost almost $1000 (it is less than half full), and it will take longer than I expect the hardware to last to spend $1000 on backups.
But it's still $4/month/TB or $48/TB-Year. Assuming a two 10TB drives are $300 each (actually can get them for less than $200) and last 5 years or warranty expires. ($300*2 drives /5 years / 10 TB = $12/TB-Year). So AWS glacier is still ~4x the cost of buying physical drives with RAID 1 and keeping them at a friends house.
Honestly if there is any cloud storage that trades resiliency for price that would be awesome. As long as the cloud storage can tell me if any of the storage has been corrupted/lost, I'd except a 10% yearly failure rate. If my home raid is 95% and the cloud is 90% then I have an effective yearly data loss of only 0.5%.
It can be expensive, so perhaps just prioritise what you actually need instead of backing up LATEST.MOVIE.2020.Remux.r250
Keep personal media metadata and download it again, maybe, but back it up?
Better still, only store what you’ll watch and delete it.
I only backup scans of truly useful legal documents, photos go to the cloud.
Everything contemporary, disposable pop culture is “backed up” online from my perspective.
Eh? We're talking ZFS here. Built-in atomic low cost snapshots are part of the core feature set. If we're talking using a pool and backing up another pool it's a reasonable baseline assumption that one would be using either their own or one of the many mature scripts to have regular automatic snapshots and retention schedule. Ie., once every 10 min for a day, once an hour for a week or two, once a week for a year, and monthly thereafter (or whatever fits your use case), along with preservation of any manual custom snapshots. I mean, it's right there, for free.
Does it make sense to double your cost (/halve your capacity) by backing up the whole thing, especially when the backup is likely to be more spinning rust? I've recently chosen to do so (while also backing up the critical data several different ways), but haven't always. I can understand people who still choose otherwise. Either way my main concern is a single raidz3 and I'm going to have a bad week if I lose that, independent of what can be rebuilt.
In general, personal users of ZFS are very different than institutional users of ZFS. Hopefully not too divergent, so those raidz code paths still receive lots of testing and support. But you need to always keep this in mind when reading any advice about ZFS.
There is backup because a disks are unreliable and fail randomly. RAID is designed to solve this.
There is backup because you accidentally deleted a file. There is backup because ransomware encrypted your files. RAID with snapshots solve these (arguably better than most other backup systems).
There is backup because your main computers (phone) might break. NAS systems are a good place to backup these.
There is backup because your house burned down [or otherwise is destroyed]. This is the only one that RAID doesn't solve. (even then you can do offsite NAS)
What risks do you need to mitigate? Once you have that list you can decide what you mitigations to apply. RAID is a very useful piece of this and so saying RAID is not backup is not helpful and may harm people from making useful backups because they let the search for perfection delay them.
It really is as simple as that, and it is helpful to remind people so they do not suffer the harms likely to result from mistakenly believing that RAID is a backup.
your backup pool doesn't have to match your working pool. it certainly doesn't have to be the same size. it just has to be larger than the data you've got.
so you can build a big 64TB pool, and back it up to a set of external USB drives which expand as your actual data expands. similarly you can turn on a bit more compression for the backup pool than you might want on the main one.
Not with mirrored vdevs, which you can expand pair by pair.
I'm not arguing for the article, just pointing out your error. The article is very flawed and is bad advice. Not because it's bad per se, but the reasoning fails at basic mathematical analysis. There certainly are valid reasons to use mirrored vdevs. One might be, so you can more easily expand your pool incrementally.
Anyway, from personal experience, my thought is that home users should give up on the idea of "incremental expansion" anyway. Double up each time. I'm surprised that you want to say home users aren't going to use 8 drive setups, while at the same time decrying mirrors in favor of parity. If you have a low drive count, the storage efficiency of parity puts you close to that of mirrors anyway. raidz2 with 4 drives as you suggest makes almost no sense vs mirrors.
But that advice might not be relevant for the use-cases discussed here, something to keep in mind.
I meant that home-users don't have to be limited by 8-drive setups.
Actually losing a mirror vdev doesn’t lose the whole pool anymore for several years now. I’ve recovered data off a zpool where I lost one of three mirrored vdevs. It’s not pretty, but your data is still there. Any files on the missing drives are just 0 bytes.
It's $130 for an 8TB USB drive at Best Buy. If you don't mirror your backup, that's $16/TB cost, which is quite reasonable.
Not true. If you lost all the drives in a mirror vdev, you lost those files not the entire pool.
More importantly, mirrors are not limited to two drives. You can have any number.
I use mirror vdevs with 4 drives.
And if one of your disks failed, and age was a factor… you’re going to be sweating bullets wondering if another will fail before your resilver completes.
So every every single time you loose any drive in a mirror setup you risk all the data on all drives in the entire pool. I sure do hope you aren't on vacation and/or have to order a drive online.
It all depends on your use case. For me, raidz3 wins easily. Performance during resilvering is not something most users would suffer that much from anyway either. And that 8-drive recommendation comes from many factors and don't apply to most home-users anyway. Not that you should go overboard with it but it will easily pay for fast cache or whatever else you might want.
If performance was the goal you would not be using spinning rust anyway, and if you are still limited by a single gbit then don't even think about it (but don't over-utilize your pool).
But there are still lots of potential ways for your data to die, and you still need to back up your pool. Period. PERIOD!
Of course! Yet for home users there is not a single reasonable way to do it if you have decently sized pool. There is bound to be sacrifices on what you choose to backup.
Except for maybe another pool. Which is going to hurt since ZFS with buying everything up front is VASTLY more expensive than RAID where you can grow the array as needed - under the assumption that the storage needs grow slowly, which they typically do for home users.
As a ZFS user and fanboy the temptation of a dual raid6 setup is tempting. But I can't compromise on the filesystem so in the end I've compromised on backups instead. Likely not the smartest move considering how rare bitrot is, I am very well aware.
For many drives I'd go for raidz3. And for a 4-drive NAS I'd go with raidz2 rather than a mirror setup for the ease of mind.
For fast SSD pools I'd go with mirrors. Much easier to backup the entire pool as well.