RAIDZ1, RAIDZ2 and RAIDZ3 are ZFS’s single-, double- and triple-parity vdev layouts: each survives one, two or three failed disks per vdev and gives up roughly that many disks of capacity. RAIDZ2 is the sensible default for most pools; RAIDZ1 suits small groups of small disks, and RAIDZ3 suits wide groups of very large drives.
Once you have decided that a pool will use RAIDZ rather than mirrors, the parity level is close to irreversible. The documentation separates the three levels by exactly one thing, the number of devices that can fail without data loss, but that single difference propagates into capacity, rebuild risk and how long the pool can sensibly live.
RAIDZ1 vs RAIDZ2 vs RAIDZ3 at a glance
For eight equal 18 TB disks, the documented approximation gives:
| Level | Parity equivalents | Failed disks tolerated per vdev | Minimum disks per vdev | Capacity before other overhead |
|---|---|---|---|---|
| RAIDZ1 | 1 | 1 | 2 | 126 TB |
| RAIDZ2 | 2 | 2 | 3 | 108 TB |
| RAIDZ3 | 3 | 3 | 4 | 90 TB |
Parity is distributed across the members; these are capacity equivalents, not dedicated parity drives. The figures exclude padding, metadata and free-space headroom.
Share of raw space kept, by vdev width, from the same (N − P) ÷ N approximation:
| Disks in the vdev | RAIDZ1 | RAIDZ2 | RAIDZ3 |
|---|---|---|---|
| 4 | 75% | 50% | 25% |
| 6 | 83% | 67% | 50% |
| 8 | 88% | 75% | 63% |
| 9 | 89% | 78% | 67% |
| 12 (above the recommended width) | 92% | 83% | 75% |
Each extra parity level costs one disk’s worth of space, a smaller fraction of a wider vdev. A six-wide RAIDZ3 keeps the same 50% as two-way mirrors.
A pool distributes data across vdevs
Redundancy belongs to each data vdev. Adding another vdev adds space, but it does not protect the first one: losing a data vdev beyond its redundancy can make the entire pool unavailable. For two RAIDZ2 groups, count failures within each group rather than treating four parity equivalents as a pool-wide allowance.
What RAIDZ, RAIDZ1, RAIDZ2 and RAIDZ3 are
The zpoolconcepts(7) man page defines them without ceremony. RAIDZ is a distributed-parity layout similar to RAID-5 and RAID-6 that does not suffer from the write hole, because copy-on-write means data and parity never become inconsistent after a power loss. raidz1 is single parity, raidz2 is double parity, raidz3 is triple parity, and the bare raidz type is an alias for raidz1. RAID-Z, RAID Z and RAIDZ-1 are spellings of the same vdev types.
The level is just the vdev keyword given to zpool create. The first example in zpool-create(8) builds one six-disk single-parity group:
zpool create tank raidz sda sdb sdc sdd sde sdfSwap in raidz2 or raidz3 for double or triple parity; repeating a keyword with more disks adds a second RAIDZ vdev.
Two sizing constraints come from the same page. A RAIDZ group with N disks of size X and P parity disks holds approximately (N − P) × X bytes and survives P devices failing. The minimum number of devices in a group is one more than the parity count, and the recommended number is between three and nine to help performance.
That recommended range is the part most people skip. A twelve-wide or sixteen-wide RAIDZ2 will build and it will work, but it sits outside what the project recommends, and the reasons show up in the sections below.
RAIDZ vs traditional RAID 5 and RAID 6
RAIDZ1 does the job of RAID 5, RAIDZ2 of RAID 6, and RAIDZ3 adds a third parity disk beyond either. The difference is that parity lives inside ZFS, which knows every block’s size and checksum, rather than in a controller below the filesystem. That removes the write hole and lets ZFS identify and repair bad data.
| Hardware RAID 5 or 6 | RAIDZ1, RAIDZ2, RAIDZ3 | |
|---|---|---|
| Parity disks per group | 1 or 2 | 1, 2 or 3 |
| Stripe width | Fixed by the array | Dynamic: every block is its own stripe |
| Partial-stripe writes | Exposed to the write hole | Full-stripe and copy-on-write, no write hole |
| Silent corruption during a rebuild | Behaviour undefined | Checksums decide; damaged files reported in zpool status |
Per the Wikipedia ZFS article, full-stripe writes also skip RAID 5’s read-modify-write cycle, and a resilver examines only data ZFS knows to be out of date (zpool-scrub(8)).
Do not layer RAIDZ over a hardware RAID volume: the OpenZFS hardware guidance says such controllers should not be used with ZFS, and ZFS hardware requirements covers why and the HBA alternative. If Btrfs parity RAID is the alternative, see ZFS vs Btrfs for a home NAS.
Capacity is not simply N minus P
The (N − P) × X formula in the documentation is explicitly approximate, and the gap between it and reality widens as groups get wider.
RAIDZ does not use a consistent stripe width. Data and parity are striped across the disks in the group, and each block carries parity proportional to its own size rather than to the group’s width. Small blocks in a wide group therefore pay a much higher parity ratio than the naive formula suggests, and allocation padding adds more on top. The effect is largest exactly where people expect wide groups to shine: a pool of many small records, or zvols with a small volblocksize, spread over a wide RAIDZ vdev.
The OpenZFS RAIDZ page puts numbers on it. A three-disk RAIDZ1 with ashift=12 storing 4K records writes one 4K data and one 4K parity block: 50% usable, like a two-way mirror. With 128K records it writes 192K on disk for 128K of data, about 66%. Whenever a record fits in one sector, RAIDZ parity costs as much as a mirror of equal redundancy: a third of raw space usable on RAIDZ2, a quarter on RAIDZ3.
Two practical consequences follow. First, when a wide group is used for bulk sequential data, a larger recordsize on those datasets can reduce the loss, because the parity overhead is amortised over a bigger block; larger records also help zstd, as the LZ4 vs ZSTD comparison shows. Second, any capacity figure produced before the pool exists is an estimate. The ZFS and RAIDZ capacity calculator on this site applies the (N − P) formula with an explicit fill-level margin. Its output should not be read as the number zfs list will eventually show.
Failure tolerance and the rebuild window
The headline difference is simple: RAIDZ1 tolerates one failed device per vdev, RAIDZ2 two, RAIDZ3 three. The argument for spending a disk on the next parity level is not really about the first failure, though. It is about what happens during the rebuild.
After a disk fails, the vdev is running without its full redundancy until the replacement finishes resilvering. Reconstruction reads surviving members and competes with application I/O. Allocated data, device performance and workload affect the duration; disk capacity alone cannot predict a fixed number of hours or days. During that interval the vdev has already used part of its redundancy budget.
That is why the sensible reading of the levels is by exposure rather than by capacity:
- RAIDZ1 is defensible for small groups of small disks, for data that is genuinely reproducible, or for a pool whose rebuild finishes quickly. On a wide group of high-capacity drives it leaves no margin during a multi-day resilver.
- RAIDZ2 is a useful starting choice for general-purpose pools. After one device failure it retains tolerance for another device failure in that vdev, until further faults consume that margin.
- RAIDZ3 earns its third disk on wide groups, on very large drives, and on archival pools where a rebuild takes long enough that a second and third failure stop being hypothetical. The relative cost of the extra parity disk also falls as the group widens.
A useful reframing: choosing an extra parity disk over an extra data disk is usually cheaper than the alternative insurance, which is a faster restore path from backup.
RAIDZ1 vs RAIDZ2: is one parity disk enough?
For most pools, no. RAIDZ1 survives one failure and then has no redundancy until the resilver finishes, so an unreadable sector on a surviving disk during that window can cost the file it belongs to. RAIDZ2 keeps one parity level in reserve through the rebuild. Pick RAIDZ1 only for narrow vdevs of small disks holding reproducible or backed-up data.
“RAIDZ vs RAIDZ2” is the same question, since bare raidz means RAIDZ1. The second parity disk costs most at small widths: a four-disk RAIDZ2 stores a third less than RAIDZ1, a six-disk one a fifth less. A four-disk RAIDZ2 matches the 50% of two striped two-way mirrors but survives any two failures, where the mirrors survive two only if they hit different mirrors. Mirrors still win on random reads, per the RAIDZ page.
RAIDZ2 vs RAIDZ3: when is triple parity worth it?
Triple parity pays off on wide vdevs, large drives and long-lived archives, where a resilver runs long enough that two more failures in the same vdev are plausible. On a nine-disk vdev RAIDZ3 keeps 67% of raw space against RAIDZ2’s 78%; on six disks it drops to 50%, no better than mirrors.
After one failure, RAIDZ2 rebuilds with RAIDZ1’s margin and RAIDZ3 with RAIDZ2’s: a second failure mid-rebuild still leaves parity to repair bad sectors.
Parity covers slow disks too. Since OpenZFS 2.4, up to nparity persistently slow members can sit out reads, which are reconstructed from parity instead (RAIDZ documentation, 2.4.0 release notes).
Past nine disks, weigh RAIDZ3 against splitting. Twelve disks as one RAIDZ3 vdev keep 75% and survive any three failures; as two six-disk RAIDZ2 vdevs they keep 67%, survive two per vdev and give roughly twice the random IOPS.
Narrow groups beat one wide group
Random IOPS scale with the number of vdevs, not with the number of disks. A read of a full-size record (128K by default) in a RAIDZ group touches every data member of that group, so a single RAIDZ vdev delivers roughly the random IOPS of one disk regardless of how many disks are in it. The dRAID documentation makes the same relationship explicit for its own layout, approximating delivered random IOPS as the number of redundancy groups multiplied by single-drive IOPS.
Twenty-four disks arranged as two twelve-wide RAIDZ2 vdevs and as four six-wide RAIDZ2 vdevs give different capacity tradeoffs. The second spends eight disk equivalents on parity rather than four and provides more independently operating vdevs. It also stays inside the documented three-to-nine recommendation. For the separate choice between mirrors and RAIDZ, including random workloads and incremental growth, use TrueNAS Guide’s RAIDZ vs mirrors pool-design comparison.
dRAID, when rebuild time dominates
For large disk counts there is a third option. A dRAID vdev is built from multiple internal RAIDZ groups distributed across all children, with integrated distributed hot spares rather than idle spare drives. Because it uses a fixed stripe width, it can resilver fully sequentially, which is what makes rebuilds fast enough to matter at scale.
The tradeoffs are documented and real. The fixed stripe width raises the minimum allocation size, with the default of eight data devices and 4 KiB sectors giving a 32 KiB minimum, which can hurt both compression ratio and small-file efficiency. The documentation recommends adding a mirrored special vdev if a dRAID pool will hold many small blocks. Capacity is approximately (N − S) × (D / (D + P)) × X, where S is the number of distributed spares.
What you can change afterwards, and what you cannot
This is the part worth reading before you type zpool create.
You cannot change the parity level of an existing vdev. A RAIDZ1 vdev never becomes a RAIDZ2 vdev. The only migration is to build a new pool and send the data across.
You cannot remove a RAIDZ top-level vdev. The zpool-remove(8) man page states that top-level vdevs can only be removed if the primary pool storage contains no top-level RAIDZ or dRAID vdev, all top-level vdevs share the same ashift, and encryption keys are loaded. A RAIDZ vdev added by mistake is permanent for the life of the pool.
You can now widen a RAIDZ vdev. RAIDZ expansion shipped in OpenZFS 2.3.0, released in January 2025 according to The Register. Via zpool attach pool raidz2-0 <newdisk>, it turns a six-wide RAIDZ2 into a seven-wide RAIDZ2 in place; fault tolerance is unchanged, so a RAIDZ2 stays a RAIDZ2. The operation requires the raidz_expansion pool feature and a disk at least as large as the smallest existing member, and progress is reported by zpool status. The documented caveat matters for capacity planning: the expansion rewrites existing data across the wider group, but old blocks keep their original data-to-parity ratio, so only blocks written after the expansion use the new ratio. Expansion adds space; it does not retroactively improve the efficiency of what was already there.
You can add hot spares, and they are not a substitute for parity. A spare shortens the time before a rebuild starts. It does nothing about the exposure during the rebuild itself, which is the risk the parity level actually addresses.
Support vdevs, alignment and scrubs
Support vdevs need their own failure plan
A SLOG serves synchronous write logging; it does not add a parity level. An L2ARC device caches reads and consumes RAM for bookkeeping. A special vdev holds metadata and optionally small data blocks, so it is essential storage, not a disposable cache. Give it suitable redundancy: RAIDZ data vdevs do not protect a separate, unmirrored special device. The OpenZFS pool concepts manual describes these allocation classes.
Separate fixed choices from dataset settings
Choose sector alignment before creating a vdev. Its ashift determines the minimum I/O size and remains associated with that vdev; changing the pool property later does not realign existing vdevs. See zpoolprops(7).
Dataset recordsize and compression can be changed later. Existing file blocks are not automatically rewritten to match the new properties, so keep that distinction in any migration plan. These settings are documented in zfsprops(7).
Keep scrubs and independent backups in the plan
A scrub verifies checksums and repairs damage where a valid redundant copy is available. Schedule it while the pool is healthy so damaged blocks have a chance to be found before a device failure consumes redundancy. A resilver covers data known to need reconstruction; it does not replace routine scrubs. The scrub manual explains the distinction. Keep a separate backup for recovery from deletion or loss of the pool.
Choosing in one pass
Start from the rebuild window, not the capacity table.
- Estimate how long a resilver will take at your disk size and expected fill level.
- Decide how much redundancy each vdev should retain for the whole of that window, and let that pick the level: none left is RAIDZ1, one disk is RAIDZ2, two disks is RAIDZ3.
- Check the group width against the three-to-nine recommendation, and split into more vdevs rather than widening if the count is high.
The hardware side of the same decision, including which drive properties are fixed at vdev creation, is covered in ZFS hardware requirements. What the rebuild actually looks like when it happens is in reading a DEGRADED zpool status.
FAQ
is raidz the same as raid 5?
No, though RAIDZ1 fills the same role: one parity disk per group. The difference is that every RAIDZ block is its own full stripe written copy-on-write, so there is no write hole, and ZFS checksums find bad data and repair it from parity, which ZFS cannot do on top of a hardware RAID 5 volume.
how many disks do you need for raidz2?
Three is the technical minimum, because a RAIDZ group needs one more device than its parity count. OpenZFS recommends three to nine disks per group. Narrow groups pay heavily, though: a three-disk RAIDZ2 keeps a third of raw capacity, the same as a three-way mirror, and a six-disk group keeps two thirds.
can you convert raidz1 to raidz2 later?
No. A vdev keeps its parity level for life, and RAIDZ expansion only widens it: a RAIDZ1 that gains a disk is still RAIDZ1. Changing level means building a new pool from RAIDZ2 vdevs, moving the data with a recursive zfs send -R replication stream, which preserves snapshots and properties, then retiring the old pool.
