In raid z1 vs z2 vs z3, pick RAIDZ2 for almost every home NAS with four to eight bays: it survives any two failed disks per vdev and costs just one more drive of capacity than RAIDZ1. Keep RAIDZ1 for three or four small drives with a real backup, and RAIDZ3 for eight-plus-wide vdevs of very large drives.
That holds for most people with a four- or six-bay box and a stack of drives that cost more than they’d like to admit. The rest depends on two numbers you know before typing zpool create: bay count and drive size. Parity mechanics, padding and what you can change later are in the RAIDZ1 vs RAIDZ2 vs RAIDZ3 parity deep-dive; this page is the buying decision.
How were RAIDZ1, RAIDZ2 and RAIDZ3 compared?
Nothing here was benchmarked in-house. The comparison draws on the OpenZFS manual for capacity and width rules, the OpenZFS and Proxmox VE docs for IOPS behavior, TrueNAS for disk minimums, Backblaze’s 2025 Drive Stats for failure rates, and Adam Leventhal’s 2009 case for triple parity. The key lines:
- zpoolconcepts(7): N disks of size X with P parity disks hold “approximately (N-P)*X bytes” and survive P failures. Minimum width is P + 1, and “the recommended number is between 3 and 9.”
- Proxmox VE’s ZFS docs: “A RAIDZ of any redundancy level will approximately behave like a single disk in regard to IOPS with a lot of bandwidth.”
- TrueNAS pool docs: RAIDZ1, RAIDZ2 and RAIDZ3 require at least three, four and five disks.
- Backblaze Drive Stats for 2025: a 1.36% annualized failure rate for 2025, with 349,462 data drives monitored at year end.
- Leventhal on triple-parity RAID: capacity was outgrowing throughput, so rebuilds that took hours could stretch to days or weeks, and RAID-6 was drifting toward the reliability RAID-5 once offered.
RAIDZ1 vs RAIDZ2 vs RAIDZ3 side by side
| RAIDZ1 | RAIDZ2 | RAIDZ3 | |
|---|---|---|---|
| Parity per vdev | 1 disk | 2 disks | 3 disks |
| Failed disks survived per vdev | 1 | 2 | 3 |
| OpenZFS minimum width | 2 | 3 | 4 |
| TrueNAS and Proxmox installer minimum | 3 | 4 | 5 |
| Redundancy left during a one-disk resilver | None | 1 disk | 2 disks |
| Random IOPS per vdev | Roughly one disk | Roughly one disk | Roughly one disk |
| Nearest classic RAID level | RAID 5 | RAID 6 | None standard |
Two rows need a note. OpenZFS will build a two-disk RAIDZ1, while the TrueNAS UI and the Proxmox installer want one more disk. At the OpenZFS minimum, each level keeps exactly the space of a mirror with equal redundancy, so the minimum is never the width you want. The IOPS row is not a typo: parity level doesn’t change how many vdevs you have, and random I/O scales with vdevs. The OpenZFS RAIDZ page still says “mirrors remain the better choice when random-read IOPS is the binding constraint.”
Which RAIDZ level for 4, 5, 6 and 8 bays?
RAIDZ2 for five, six and eight bays. RAIDZ2 or two mirrors for four bays, depending on workload. RAIDZ1 only for three bays or small drives you have backed up. RAIDZ3 from about ten bays, or eight bays of very large drives holding an archive. Usable space with 16 TB drives, from the (N − P) × X approximation:
| Bays | RAIDZ1 | RAIDZ2 | RAIDZ3 | Pick |
|---|---|---|---|---|
| 3 | 32 TB (67%) | 16 TB (33%) | Not possible | RAIDZ1 plus a backup |
| 4 | 48 TB (75%) | 32 TB (50%) | 16 TB (25%) | RAIDZ2, or two mirrors for VMs |
| 5 | 64 TB (80%) | 48 TB (60%) | 32 TB (40%) | RAIDZ2 |
| 6 | 80 TB (83%) | 64 TB (67%) | 48 TB (50%) | RAIDZ2 |
| 8 | 112 TB (88%) | 96 TB (75%) | 80 TB (63%) | RAIDZ2; RAIDZ3 for big-drive archives |
| 12 (above recommended width) | 176 TB (92%) | 160 TB (83%) | 144 TB (75%) | RAIDZ3, or 2 × 6-wide RAIDZ2 |
Those figures are before padding, metadata and free-space headroom, so zfs list will show less.
Three bays. A three-disk RAIDZ2 keeps a third of raw space, the same as a three-way mirror, so the real choice is RAIDZ1 or a two-way mirror with a spare bay. RAIDZ1 suits a media library you could re-rip, not the only copy of anything.
Four bays. The most common home box and the hardest call: RAIDZ2 and two striped mirrors both keep half the raw space. For bulk storage, take RAIDZ2 and its any-two-disks tolerance. For VM disks on a Proxmox host, the Proxmox docs say mirror vdevs have “favorable behavior for VM workloads,” and two vdevs beat one on random I/O.
Five and six bays. RAIDZ2, no debate. Six-wide RAIDZ2 keeps two-thirds and sits mid-range in the recommended width. The catch on N100-class builds is ports, not parity: the OpenZFS hardware guidance says USB drives and adapters “should be considered unreliable,” so a mini-PC with a USB multi-bay enclosure isn’t a RAIDZ host. The ZFS hardware requirements guide covers the HBA route.
Eight bays. RAIDZ2 at 75% is still the default. Move to RAIDZ3 at 63% when drives are big enough that a resilver runs for days, or when the pool is the archive and a full restore would take longer than you’d tolerate.
Ten to twelve bays. You’re past the recommended width, so choose between one RAIDZ3 vdev (144 TB, survives any three failures) and two six-wide RAIDZ2 vdevs (128 TB, two vdevs of IOPS, and each rebuild reads five disks instead of eleven). Backup or media box: one RAIDZ3. Anything you run apps against: two RAIDZ2.
Where each one wins
RAIDZ1: terabytes per drive bought
It wins one contest. Good homes are a backup target that’s already the second copy, scratch space, and a three-bay box of small drives. On ZFS, an unreadable sector during a RAIDZ1 resilver typically costs the file that block belongs to, not the pool: ZFS stores an extra copy of all metadata by default (redundant_metadata in zfsprops(7)), and zpool status -v lists every file with errors (zpool-status(8)). That’s still data loss, and a second whole-disk failure mid-resilver takes the vdev and the pool with it.
RAIDZ2: the default for a reason
After one failure RAIDZ2 still has a parity disk, so the resilver can repair a bad sector it hits instead of writing off a file. That is what the extra drive buys. Parity also covers drives that are dying slowly: since OpenZFS 2.4, a persistently slow disk can sit out reads, which are reconstructed from parity, with up to nparity disks sitting out at once, per the RAIDZ page. RAIDZ2 can carry two.
RAIDZ3: wide vdevs, huge drives
Leventhal’s triple-parity argument has aged well: 20 TB-plus models made up 22.81% of the drives in Backblaze’s 2025 report. The third parity disk also gets cheaper as vdevs widen, costing half of a six-wide vdev but a quarter of a twelve-wide one. At six bays RAIDZ3 matches two-way mirror capacity with RAIDZ’s single-disk IOPS, which only makes sense if surviving any three failures is a hard requirement.
Does drive size change the answer?
Yes, more than bay count does. Parity level is a bet on the rebuild window, and that window grows with how much data the surviving disks must read. Bigger drives stretch it, fuller pools stretch it further, and a pool still serving Plex while it resilvers stretches it again.
Backblaze’s 1.36% annual rate makes any single failure look rare, and for the first failure it is. The parity decision is about the second failure arriving during the first rebuild, under the heaviest sustained read load the pool will see, on drives likely bought in the same order with the same hours on them. A fleet-wide average says nothing about that kind of correlated timing.
So as drives get bigger at the same width, move up a parity level. Small drives in a narrow vdev can live with RAIDZ1 if backed up. Large drives in four- to eight-wide vdevs want RAIDZ2. The biggest drives in eight-plus-wide vdevs holding data you can’t quickly restore are where RAIDZ3 earns its keep.
Which one should you pick?
RAIDZ2, for any home NAS with four to eight bays. Choose something else only if one of these is true:
- The pool hosts VM disks or databases: use mirrors, not RAIDZ at any level.
- You have three bays, or small drives and a tested backup: RAIDZ1 is fine.
- You have ten or more bays, or eight bays of very large drives holding an archive: RAIDZ3, or split into two RAIDZ2 vdevs.
Buy the parity you want on day one. OpenZFS 2.3.0 added RAIDZ expansion, but the RAIDZ page is explicit that widening leaves fault tolerance unchanged, so a RAIDZ1 that gains a disk is still RAIDZ1.
None of the three is a backup. Parity covers dead disks, not a deleted dataset or a pool that won’t import. Keep an off-box copy of what matters; if a cloud bucket is the easiest way to do that, the cloud is fine for the job. Scrub regularly so bad sectors surface while redundancy is intact, and when a disk does die, the DEGRADED pool walkthrough covers the swap. Weighing Btrfs parity RAID instead? See ZFS vs Btrfs for a home NAS.
FAQ
is raidz1 safe with large drives?
Only if the data also lives somewhere else. During a RAIDZ1 resilver the vdev has no parity left, so an unreadable sector costs a file and a second disk failure costs the pool. Large drives stretch that exposed window, potentially to days. With large drives and no other copy, spend the extra disk on RAIDZ2.
is raidz3 overkill for a home nas?
Usually, yes. On four to six bays RAIDZ3 keeps between a quarter and half of raw space, no better than two-way mirrors, and still delivers roughly one disk of random IOPS. It earns its place on wide vdevs of very large drives holding an archive, where a resilver runs for days and a full restore would take far longer.
is raidz2 slower than raidz1?
Not in a way most home setups notice. Proxmox’s documentation says a RAIDZ vdev of any redundancy level behaves roughly like a single disk for IOPS. Streaming bandwidth scales with data disks, per the OpenZFS RAIDZ page, so at equal width RAIDZ2 gives up one data disk of sequential throughput, and the network link usually caps you first.
how many drives do you need for raidz3?
Four is the OpenZFS minimum, because a RAIDZ group needs one more disk than its parity count, and TrueNAS and the Proxmox installer require five. Neither is a sensible width, since four disks in RAIDZ3 keep a quarter of raw space. RAIDZ3 starts paying for itself at eight or more drives, keeping 63% or better.
