Except no. No no no. It’s the reason why I honestly would never touch raid5, but raidz is fine. There’s the massive difference between raid5/6 vs raidz1/z2. A URE during a raid 5 or 6 rebuild means your pool is gone. A URE during a raidz or z2 rebuild means you lose a file or two. This is different universes in terms of impact. And also why you have backups.

Before we go into specifics, consider your use case. Are you storing photos, MP3's and DVD rips? If so, you might not care whether you permanently lose a single block from the array. On the other hand, if it's important data, this might be a disaster.

The statement that RAIDZ-1 is "not good enough for real world failures" is because you are likely to have a latent media error on one of your surviving disks when reconstruction time comes. The same logic applies to RAID5.

ZFS mitigates this failure to some extent. If a RAID5 device can't be reconstructed, you are pretty much out of luck; copy your (remaining) data off and rebuild from scratch. With ZFS, on the other hand, it will reconstruct all but the bad chunk, and let the administrator "clear" the errors. You'll lose a file/portion of a file, but you won't lose the entire array. And, of course, ZFS's parity checking means that you will be reliably informed that there's an error. Otherwise, I believe it's possible (although unlikely) that multiple errors will result in a rebuild apparently succeeding, but giving you back bad data.

Since ZFS is a "Rampant Layering Violation," it also knows which areas don't have data on them, and can skip them in the rebuild. So if your array is half empty you're half as likely to have a rebuild error.

You can reduce the likelihood of these kinds of rebuild errors on any RAID level by doing regular "zpool scrubs" or "mdadm checks"of your array. There are similar commands/processes for other RAID's; e.g., LSI/dell PERC raid cards call this "patrol read." These go read everything, which may help the disk drives find failing sectors, and reassign them, before they become permanent. If they are permanent, the RAID system (ZFS/md/raid card/whatever) can rebuild the data from parity.

Even if you use RAIDZ2 or RAID6, regular scrubs are important.

One final note - RAID of any sort is not a substitute for backups - it won't protect you against accidental deletion, ransomware, etc. Although regular ZFS snapshots can be part of a backup strategy.

RaidZ2. You don’t want to be vulnerable during resilvering. RaidZ2 can tolerate 2 drive failures, whereas RaidZ1 can only tolerate 1. Thus, if 1 drive fails on a RaidZ1, your data is vulnerable while your spare resilvers. With RaidZ2 you’ll have to purchase and swap out a replacement drive, but at least your data is not going to be vulnerable during resilvering.

Be aware that if another drive fails while doing a rebuild, it is almost certain that all data will be lost. General recommendation is to do RAIDZ2 or greater, but it all depends on whether there is a full backup elsewhere and general risk aversion to data loss.

Even given what one of the other answers here laid out, namely that ZFS only works with actual used blocks and not empty space, yes, it is still dangerous to make a large RAIDZ1 vdev. Most pools end up at least 30-50% utilized, many go right up to the recommended maximum of 80% (some go past it, I highly recommend you do not do that at all, for performance reasons), so that ZFS deals only with used blocks is not a huge win. Also, some of the other answers make it sound like a bad read is what causes the problem. This is not so. A bit rot inside a block is not what's going to screw you here, usually, it's another disk just flat out going bad while the resilver from the first disk going bad is still going on that'll kill you.. and on 3 TB disks in a large raidz1 it can take days, even weeks to resilver onto a new disk, so your chance of that happening is not insignificant.

My personal recommendation to customers is to never use RAIDZ1 (RAID5 equivalent) at all with > 750 GB disks, ever, just to avoid a lot of potential unpleasantness. I've been OK with them breaking this rule because of other reasons (the system has a backup somewhere else, the data isn't that important, etc), but usually I do my best to push for RAIDZ2 as a minimum option with large disks.

Also, for a number of reasons, I usually recommend not going more than 8-12 disks in a raidz2 stripe or 11-15 disks in a raidz3 stripe. You should be on the low-end of those ranges with 3 TB disks, and could maybe be OK on the high-end of those ranges on 1 TB disks. That this will help keep you away from the idea that more disks will fail while a resilver is going on is only one of those reasons, but a big one.

If you're looking for some sane rules of thumb (edit 04/10/15 - I wrote these rules with only spinning disks in mind - because they're also logical [why would you do less than 3 disks in a raidz1] they make some sense even for SSD pools but all-SSD pools was not a thing in my head when I wrote these down):

• Do not use raidz1 at all on > 750 GB disks.
• Do not use less than 3 or more than 7 disks on a raidz1.
• If thinking of using 3-disk raidz1 vdevs, seriously consider 3-way mirror vdevs instead.
• Do not use less than 6 or more than 12 disks on a raidz2.
• Do not use less than 7 or more than 15 disks on a raidz3.
• Always remember that unlike traditional RAID arrays where # of disks increase IOPS, in ZFS it is # of VDEVS, so going with shorter stripe vdevs improves pool IOPS potential.

most people on this reddit are data driven folks and can weigh the real against the hype I think you're taking a narrow view of "data driven" on this it costs me $X to buy an extra hard drive and run raidz2 instead of raidz1 if I experienced data loss due to raidz1, it would take Y hours of my time to recover from backups the value I place on Y hours of my time is significantly larger than $X. so the exact failure probability doesn't matter to me. I happily pay $X extra as an insurance policy.

In short: no. I have been running the exact same setup for years without issues. Two things to consider: Back up your containers so they can be restored if your system disks fail Back up your systems config files for easier recovery should both disks fail