RAIDZ1 vs RAIDZ2: Parity, Resilver Risk, and Which to Pick
RAIDZ1 survives one disk failure, RAIDZ2 survives two. What that means for usable capacity, resilver risk, and how to choose at each vdev width.
If you want ZFS RAIDZ1 vs RAIDZ2 explained in one sentence: RAIDZ1 spends one disk’s worth of capacity on parity and survives one disk failure per vdev, while RAIDZ2 spends two and survives any two. That sentence is accurate and nearly useless, because the decision doesn’t live in the happy path. It lives in the week a disk dies, the vdev goes degraded, and the surviving drives spend days grinding through a resilver. This post covers what the parity levels actually do, why drive size changed the answer, and which one to build.
What parity actually buys you
RAIDZ is ZFS’s software parity RAID. Per the OpenZFS zpoolconcepts documentation, a raidz group can have single, double, or triple parity (raidz1, raidz2, raidz3), sustaining one, two, or three disk failures respectively without losing data. Plain raidz is an alias for raidz1.
Capacity math is straightforward: a vdev of N disks of size X with P parity disks stores roughly (N-P) × X bytes. So a 6-wide RAIDZ1 of 10 TB drives gives about 50 TB usable; the same six disks in RAIDZ2 give about 40 TB. The docs recommend keeping a raidz group between 3 and 9 disks wide for performance, and the TrueNAS ZFS primer draws a harder line at no more than 12 disks per vdev.
Two structural points that trip up people coming from hardware RAID:
- Redundancy lives at the vdev level, not the pool level. A pool striped across two RAIDZ1 vdevs still dies if any single vdev loses two disks.
- Parity level is permanent. Since OpenZFS 2.3.0 (January 2025) you can widen an existing raidz vdev by adding disks, which fixed the old “buy every drive upfront” problem, but expansion never changes parity. A RAIDZ1 stays RAIDZ1 forever. You pick your parity level once, at creation, and live with it.
The decision is really about resilvers
Here’s the part the capacity math hides. When a disk in a RAIDZ1 vdev fails, you’re not just down one disk. You’re running with zero redundancy while the replacement resilvers, and a resilver is the most punishing workload the surviving disks will ever see: ZFS reads the allocated data across every remaining drive in the vdev to reconstruct the missing one. Any second failure during that window, whether a full drive death or an unrecoverable read error on a sector that hasn’t been touched in years, means data loss.
That window used to be short. On the 1 to 2 TB drives of a decade ago, a resilver finished in hours. On today’s 16 to 24 TB drives, a resilver of a well-filled vdev can stretch into days, and the exposure window grows with it. This is why the TrueNAS primer states flatly that RAIDZ1 is not recommended for drives over 1 TiB. That threshold is conservative to the point of being widely ignored, and plenty of home pools run RAIDZ1 on much bigger disks without incident. But the direction of the guidance is correct, and the primer’s summary of the tradeoff is blunt: RAIDZ2 offers better availability and “significantly better mean time to data loss” than RAIDZ1.
Disk failures are also not rare events you can round to zero. Backblaze’s Drive Stats for 2024 put the annualized failure rate across roughly 299,000 production drives at 1.57%. Your NAS drives were probably bought together, from the same batch, and have spent their lives in the same case at the same temperature. When one goes, its siblings are statistically not far behind, and the resilver is exactly the stress test that finds out.
RAIDZ2’s second parity stripe exists for precisely this moment. A degraded RAIDZ2 vdev is still redundant. A read error mid-resilver is an annoyance ZFS repairs and logs, not a eulogy.
Capacity and performance: the math
The honest comparison at common widths, using 10 TB drives:
| Layout | Usable (approx) | Survives |
|---|---|---|
| 4-wide RAIDZ1 | ~30 TB | 1 disk |
| 4-wide RAIDZ2 | ~20 TB | any 2 disks |
| 6-wide RAIDZ1 | ~50 TB | 1 disk |
| 6-wide RAIDZ2 | ~40 TB | any 2 disks |
| 8-wide RAIDZ2 | ~60 TB | any 2 disks |
At 4 disks, RAIDZ2 costs you a painful 33% of your usable space versus RAIDZ1. At 8 disks it costs 14%. This is why width drives the decision: the wider the vdev, the cheaper the second parity disk is as a fraction of the pool, and the more disks there are to fail.
Performance is mostly a wash between the two. Both are parity RAID with the same character: fine for large sequential reads and writes (the TrueNAS primer notes RAIDZ1 “generally performs well when data is written and read in large chunks”), weak for small random I/O, and roughly one disk’s worth of random IOPS per vdev as a rule of thumb. If random IOPS is your constraint, the answer isn’t Z1 or Z2, it’s mirrors, and that’s a different article: RAIDZ vs mirrors.
Which one to pick
Opinionated rules that will serve you better than another hour on Reddit:
- 6 or more disks: RAIDZ2. No caveats. The capacity tax is small, the second-failure math on a wide vdev is ugly, and nobody has ever regretted the extra parity disk.
- Drives 12 TB and up: RAIDZ2, even at 4-wide. Multi-day resilvers with zero redundancy is a bet you eventually lose.
- 3 to 4 smaller drives, with real backups: RAIDZ1 is defensible. An N100 box with four 8 TB disks backing a media library that also exists elsewhere doesn’t need double parity. Take the 33% capacity win.
- Planning to grow one disk at a time: RAIDZ expansion works on both, but remember it never upgrades parity. If the pool might ever be 6-wide, start it as RAIDZ2 at 4-wide rather than painting yourself into RAIDZ1.
- Data that exists nowhere else and can’t be backed up yet: your problem isn’t parity level, it’s the missing backup. Fix that first.
Whichever you choose, schedule scrubs and SMART tests. Parity only protects data it can read cleanly, and a scrub is how latent errors get found while you still have redundancy to repair them, instead of mid-resilver when you don’t.
RAID is not a backup, even RAIDZ2
Double parity protects against disk hardware failure and nothing else. Accidental deletion, a fat-fingered zfs destroy, a failed controller, ransomware that reaches your SMB shares (a standing theme in the incident coverage over at techsentinel.news): RAIDZ2 replicates all of these faithfully across every disk. Pair whatever parity level you choose with snapshot replication to a second machine or offsite target. A RAIDZ1 pool with a real backup is in far better shape than a RAIDZ2 pool without one.
Related across the network
- OpenMediaVault vs TrueNAS vs Synology: Which NAS? — openmediavaultlab.com
- TrueNAS Storage Planning: Pools, Datasets and Shares — truenashub.com
- TrueNAS Hardware Sizing: RAM, HBA, NIC and Boot Disk — truenashub.com
- Unraid vs TrueNAS vs Synology: How to Choose — unraidhub.com
- Choosing a ZFS Pool Topology: Mirrors, RAIDZ and vdev Layout — zfsstoragehub.com
- Combo DAC/Amp vs Separates: How to Choose — dacampguide.com
- CMR vs SMR NAS Drives: What Actually Changes — nashardwareguide.com
Sources
Related
ZFS RAIDZ vs Mirror: Capacity, IOPS, and Resilver Risk
Choose 6- to 8-wide RAIDZ2 for media and bulk storage, or two-way mirrors for VMs and databases. Compare usable capacity, fault tolerance and growth.
TrueNAS Pool Won't Import? 5 zpool Fixes That Work
TrueNAS pool won't import, or I/O is suspended? Decode UNAVAIL, FAULTED and DEGRADED, fix missing devices, and import read-only to rescue your data.
TrueNAS Zvol vs Dataset: Block vs File Storage
Use a TrueNAS dataset for SMB, NFS and app files; use a zvol for iSCSI or a VM's raw disk. Compare recordsize, volblocksize and snapshots.