Selfhosted

RAID is not a backup.

RAID is not for data safety.

RAID is for:

1. Ensuring availability of data in the face of hardware failure. That means your files don't disappear when a drive dies and you have some time to swap out for functional hardware and restore redundancy.
2. Presenting multiple drives as one larger unit. This is what striping does, and to a lesser extent the parity-mode levels.
3. Improving performance (sometimes). A RAID mirror is generally much faster to read from than any individual drive because reads can be interleaved across drive members. A stripe can be much faster because writes are distributed across drive members. This is less of a bonus today with solid state/nvme drives, but it's still applicable to spinning rust.

If your concern is protecting your data, set up a 3-2-1 backup strategy.

I was originally going to use for my important documents

Not quite what you're asking, but if your concern is avoiding data loss, if you haven't already, I'd set up a backup before I started setting up a RAID or similar setup.

While redundancy in a drive setup helps, it’s not really a backup and thus not a “safe” way to store important information on it’s own.

That said, selecting the way you setup a raid system is based on risk and utility. I have a raid1 with a hotspare for important files. And use raid5 with 3&4 drives for less important stuff. You can also optimise for reading speed for example (as the same file can be drawn from multiple drives)

I'd stay on zfs, I simply don't trust btrfs’ raid implementation. For very important documents I also set copies=2 (or 3) on that dataset, just in case.

And as others already said: 3-2-1 backups ;)

Don't use any btrfs raid levels besides mirroring. There are long-standing raid bugs that they wontfix in 5 and 6 that have led to data loss.

Filesystem doesn't really matter once you have a reliable, redundant off-site backup and recovery plan set up and tested.

Really, use what fs feels best for you. And do your backups.

Did I mention backups are important?

What about 2 mirrored pools of 2 drives each, then back up the main pool to the other with either ZFS snapshots or a tool like Restic.

Ideally you also need an offsite backup of important files too, but that gets you part way to a robust system that can handle corruption or accidental deletions.

I've been using a raid1 btrfs pool to store offline backups for around 10 years. It's 4 rotating drives (2x4TB+2x12TB). I replaced / rebalanced 3 disks with larger / newer ones already (went fine). I identified a bad usb/sata controller, and lots of bitrots on one old disk (scrub was able to correct a few thousands errors).

I'm getting around 80MB/s read/write throughput (not great but OK for offline backup). I'm able to mount it on low-powered / low-memory devices (not the case for ZFS). Scrub takes around 2 days IIRC (for around 10TB of actual data), so I run it once a year.

I keep it simple and thus am not using advanced features (dedup / encryption / snapshots / subvolumes / raid5/6/10). So far its a good match for my needs.

Maybe you could switch to a raid10 (mirrored striped vdevs) for faster rebuild time.

BTRFS is relatively similar to ZFS when it comes to their raid implementation, though using raid5 or raid6 comes with some caveats.

For your situation I would be more likely to go with a single drive with btrfs and dup for metadata redundancy. Regular snapshots and scrubs.

Use a second drive in the same system with btrfs to store snapshots at wider scheduled intervals. These will be bigger since no CoW on the separate file system. Scheduled scrub here too.

Use a third drive with ext4 as a backup target using a separate backup mechanism.

Use the fourth drive as a spare, or in a separate location as a target to send the backups if you don't already have an off-site solution.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #314 for this comm, first seen 25th May 2026, 11:10] [FAQ] [Full list] [Contact] [Source code]

If rebuild time is truly your main concern, you could configure the 4 drives as raid 1+0. On truenas I think it would be called a pool of 2 mirror vdevs. It would give you much faster rebuild time and still have 1-2 drive failure tolerance.

BTRFS is not production ready (by their own admission)

1 disk redundancy leaves you exposed whenever you have to rebuild ... has significantly higer chances of having a second disk fail so you should use double redundancy. Raid z2 doesn't make sense because with raid z10 you get performance gains AND double redundancy.

Go with raid z10

If you're storing, then offline, read only, checksummed and preferably encrypted. And above all, several tested backups. I'm partial to making erofs images from dirs, but any archive that fits the content type works.

For the random access cache on top, whatever.

I have been enjoying using ZFS, although it's a not a killer filesystem for every scenario, I think it would be the best solution for you. also, you can try the "free consulting" on the 2.5 Admins podcast (show@2.5admins.com). Jim and Allen are ZFS lovely weirdos, but they can explain better why would be ZFS a better solution for your case. Give it a try. I have done it before and really helped me.

Btrfs raid5/6 support is unstable/experimental and cause some serious issues in the past, so it isn't really recommended.

Since you only have 4 drives you could do a pair of mirrors with btrfs, but you aren't guaranteed to be able to handle two drives failing (depends on which two drives fail). So zfs with raidz2 is the best protection you can get, and it matches the capacity you would get from mirrors.

Rebuild time isn't great, but you would need a second drive to fail plus at least a read failure on another drive before you have issues.

A bigger question would be how soon would you have a replacement? If you already have a spare on hand I wouldn't worry about rebuild time at all, but if you are expecting to wait potentially weeks for a warranty replacement your chances of the second failure go up.

Even if you had a second failure and additional read failure is unlikely (how often do you see read failures when you run a scrub). Combine that with your backups.... You should have very little to worry about.

If two drives failed and you ran into a couple of sectors that can't be read ZFS continues to operate just fine, except for the failed file. The file with the failed blocks shows up in zpool status so you know exactly where the corruption is, and you can just copy that single file from your backups and everything is back to normal.

If your files are mostly WORM files like media/documents then your backups cover you really well and copying a file or two from backups isn't a concern. Vs if you are running virtual machines or DBs that are writing to their virtual disk constantly then you would start to worry about how much data you lose by rolling that file back to your past backup.