ZFS RAIDZ vs Mirror: Capacity, IOPS, and Resilver Risk

RAIDZ1 vs mirror is a trade between capacity and speed. Four disks in one RAIDZ1 vdev give three disks of usable space and survive any single failure. The same four disks as two 2-way mirrors give two disks of space, two to four times the random IOPS, and faster resilvers. Choose RAIDZ2 for bulk media and mirrors for VMs and databases.

Decide carefully, because the pool you create on day one is the hardest thing to change later. You can grow a ZFS pool, but a pool built from RAIDZ2 vdevs is a RAIDZ2 pool, full stop. Get it wrong and you are eventually destroying and rebuilding the pool.

RAIDZ vs mirrors at a glance:

RAIDZ1 vs mirror: which wins with four disks?

Mirrors win on everything except capacity and sequential writes. A 4-disk RAIDZ1 vdev stores 50% more data than two 2-way mirrors, but it has one disk’s worth of random IOPS, reads every surviving disk to resilver, and cannot survive a second failure. Striped mirrors survive two failures if each lands in a different pair.

Capacity follows the OpenZFS formulas. Per OpenZFS workload tuning, mirror read IOPS “scale with the number of drives in each mirror,” each RAIDZ vdev is “limited to the IOPS of the slowest drive,” and RAIDZ wins sequential writes. zpool remove cannot evacuate vdevs from a pool containing RAIDZ.

Four disks can fail in six different pairs. With two mirrors, two of those pairs sit in the same mirror and take the pool down; RAIDZ1 dies on all six. To survive any two failures on four disks, use RAIDZ2: the same 20 TB as two mirrors, with RAIDZ’s single-disk IOPS.

Mirrors also rebuild more gently. A replacement copies from one partner, and OpenZFS can reconstruct a mirror sequentially (zpool attach -s) to restore redundancy fast, then scrubs to verify checksums. With three disks, the choice is RAIDZ1 (two disks of space, one failure) or a 3-way mirror (one disk of space, two failures).

ZFS RAID types in TrueNAS

A ZFS pool is built out of vdevs (virtual devices). A vdev is one or more physical disks grouped in a specific redundancy topology. A pool stripes data across its vdevs. Lose a vdev, lose the pool. Redundancy lives at the vdev level, not the pool level.

The TrueNAS 25.10 pool wizard offers Stripe, Mirror, RAIDZ1 to RAIDZ3 and dRAID1 to dRAID3. Mapped to hardware RAID:

The RAIDZ minimums come from TrueNAS’s pool documentation, and the RAID 50 and 60 comparisons from its pool management guide. OpenZFS calls RAIDZ “similar to RAID-5/6” without the write hole; plain raidz means raidz1. dRAID adds distributed hot spares, but TrueNAS recommends RAIDZ “whenever a dRAID vdev would have fewer than 10 data storage devices.” RAIDZ3 is rare at home.

The honest comparison

iXsystems’ Six Metrics for Measuring ZFS Pool Performance series estimates each layout from drive specs: 12 × 6 TB disks, each assumed to do 100 MB/s streaming and 250 IOPS. The RAIDZ rows come from part two.

Six mirrors deliver six times the read IOPS of two RAIDZ2 vdevs; the RAIDZ2 pool holds a third more data and survives any two failures per vdev. Two things in this table matter most:

1. RAIDZ vdevs do not scale IOPS. A six-drive RAIDZ2 vdev has roughly the random-write IOPS of a single disk. To increase random IOPS in a ZFS pool, you add more vdevs, not wider vdevs. Mirrors scale IOPS naturally because each mirror vdev contributes its own IOPS to the pool.
2. RAIDZ resilvers stress every remaining disk in the vdev. On a wide RAIDZ vdev built from older drives, the resilver itself raises the probability of a second failure mid-rebuild.

TrueNAS stripe vs mirror: when is a stripe acceptable?

Almost never for data you care about. A stripe adds every disk’s capacity and speed together with zero redundancy, so one failed disk loses the vdev; a mirror keeps an identical copy on each disk and stores one disk’s worth. TrueNAS’s pool wizard warns a failed stripe disk “irretrievably loses all stored data.”

On two 10 TB disks that is 20 TB striped versus 10 TB mirrored. In the 12-disk estimates above, mirrors match the stripe’s read IOPS and give up half its write throughput. ZFS also repairs a bad block from a good copy only “on a pool that is mirrored or uses RAIDZ,” per the TrueNAS ZFS primer; a stripe detects corruption but cannot fix it.

Started with one disk? zpool attach turns it into a two-way mirror when you give it a partner. Adding that disk as a new vdev instead widens the stripe. Keep stripes for scratch space and re-downloadable files.

What is RAID 10 in ZFS?

RAID 10 in ZFS is a pool of two or more mirror vdevs. There is no separate RAID 10 level: ZFS dynamically stripes data across every top-level vdev, so adding mirrors builds RAID 10. Create one with zpool create tank mirror sda sdb mirror sdc sdd, or in TrueNAS build a two-disk mirror and add more two-disk mirror vdevs.

That command is the zpool-create example for “a pool with two mirrors.” Hardware RAID controllers, the ZFS primer notes, “usually do not know which blocks are in use” and copy every block on rebuild; ZFS resilvers only allocated blocks and heals checksum errors from the other copy. A pair added with zpool add is usable immediately.

From four disks up, the real contest is ZFS RAID 10 vs RAIDZ2. At four both give 50% usable. At six, three mirrors hold three disks of data against RAIDZ2’s four; at eight, four against six. The mirrors keep their IOPS lead at every width.

How to think about the choice

Match the topology to the workload.

”I want a media library and bulk file storage”

This is the most common home NAS workload: large sequential reads and writes, low IOPS demands, capacity matters more than performance.

Use RAIDZ2. Go six-wide or eight-wide. You get ~67–75% usable capacity, survive two disk failures, and the sequential throughput is excellent. Avoid RAIDZ1 on modern multi-terabyte drives — the rebuild window is long enough that a second failure is not negligible. To see the real usable figure for a specific width and disk size, after parity, ashift padding, the ZFS slop reserve, and the 80% fill ceiling rather than the naive (n−p) guess, run the ZFS pool capacity calculator before you commit to a layout. For a Plex library specifically, see the ZFS pool layout for Plex.

”I want VMs and databases on my NAS”

VM disks (zvols, or .vmdk/.qcow2 files on a dataset) demand random IOPS. RAIDZ will be slow.

Use mirrors. Two-way mirrors give you a pool whose random IOPS scales with the number of vdevs. You lose 50% to redundancy, but you gain the responsiveness VMs and databases expect. This is the standard recommendation for a TrueNAS pool intended to host VMs or as iSCSI block storage.

”I want both”

You have two reasonable options:

1. Two pools. One mirror-based pool for VMs/databases, one RAIDZ2 pool for bulk storage. The downside is you commit drive bays to each, and you cannot grow one at the expense of the other.
2. One RAIDZ2 pool with a special vdev or SLOG. Adding a fast NVMe special vdev (mirrored, always) can hold metadata and small blocks on flash, dramatically improving random read performance for things like browsing large datasets and small-file workloads. This does not fix sustained VM workloads, but for many homes it is enough.

RAID-Z vs RAID-Z2: choosing parity inside a TrueNAS pool

RAID-Z (RAIDZ1) spends one disk on parity and survives one failure per vdev; RAID-Z2 spends two and survives any two. Once you have chosen RAIDZ over mirrors, compare the capacity cost of single and double parity at the width your enclosure supports. The following figures apply the OpenZFS capacity approximation, (disks - parity) × smallest disk size, to 10 TB drives. They exclude padding, metadata, reserves and TB-to-TiB conversion.

At four disks, choosing RAIDZ2 instead of RAIDZ1 reduces that starting capacity by one third. At eight disks, it reduces it from 70 TB to 60 TB, about 14%. An extra parity disk costs proportionally less in a wider vdev.

The recovery window matters as much as the initial capacity. A degraded RAIDZ1 vdev has no full-disk fault tolerance left; RAIDZ2 still tolerates one more failure. A spare shortens the wait for a replacement but does not add a parity level.

For this guide’s bulk-storage starting point, RAIDZ2 buys recovery margin at a calculable capacity cost. A smaller RAIDZ1 pool can be a deliberate choice for replaceable data with a separate backup. Neither choice eliminates the need for scrubs and SMART checks or snapshot replication.

Choose the parity level for the pool you expect to grow into: widening RAIDZ1 does not convert it to RAIDZ2. The RAIDZ1 vs RAIDZ2 guide covers resilver risk in depth. For the general three-level comparison, see ZFS Storage Hub’s RAIDZ1 vs RAIDZ2 vs RAIDZ3 guide.

Can you expand a RAIDZ pool later?

Yes. Since TrueNAS 24.10 you can widen an existing RAIDZ vdev one disk at a time, and adding a new vdev or swapping in larger disks has always worked. What you still cannot change is the parity level. The three ways to grow a pool are not interchangeable:

• Add another vdev. Always available. You can stripe a second RAIDZ2 vdev (or another mirror pair) into the pool to add capacity and, in the mirror case, IOPS. The constraint is that you commit a full vdev’s worth of drives at once.
• Replace every disk in a vdev with a larger one. Always available. Swap disks one at a time, resilvering between each, and once the last small disk is gone the vdev grows to the new size. This is covered in detail in TrueNAS pool expansion options, and the disk-swap mechanics are the same as in replacing a failed disk in a degraded pool.
• RAIDZ expansion (add a single disk to an existing RAIDZ vdev). TrueNAS introduced RAIDZ extension in 24.10 “Electric Eel”; the upstream feature shipped in OpenZFS 2.3.0, and TrueNAS 25.04 “Fangtooth” and 25.10 “Goldeye” carry it forward.

RAIDZ expansion is genuinely useful, but it has caveats:

• It does not change parity level. You can make a RAIDZ1 vdev wider, but you cannot turn RAIDZ1 into RAIDZ2; the parity count is fixed for the life of the vdev.
• Existing data keeps its old data-to-parity ratio. Blocks written before the expansion retain their original width and are simply spread across more disks, so an expanded vdev can report less usable capacity than a freshly created vdev of the same disk count until that data is rewritten.
• It does not turn RAIDZ into a high-IOPS pool. A wider RAIDZ vdev still delivers roughly one disk’s worth of random IOPS.

The practical upshot: mirrors remain the easiest topology to grow incrementally, and RAIDZ is less of a one-way door than it used to be, but the parity level you choose on day one is permanent.

Pool design mistakes to avoid

Mixing topologies in one pool. A pool with a RAIDZ2 vdev and a mirror vdev technically works, but zpool add treats it as a conflicting replication level and needs -f to accept it, and TrueNAS’s pool guide says to add a data vdev “of the same type as existing VDEVs.” ZFS then stripes across both, and the pool is effectively limited by its weakest member for failure planning. Don’t do it. Pick a topology and stick to it.

Adding a single disk as a new vdev to an existing pool. ZFS balks without -f, but it will accept the disk if forced. The result is a pool whose redundancy is gated by a single non-redundant disk. Lose that disk and the whole pool is gone. Never add a single non-redundant disk to an existing pool except as cache or log.

Building a too-wide RAIDZ vdev. Twelve-wide RAIDZ2 looks attractive for capacity efficiency. The resilver time on a 12-disk RAIDZ2 vdev with multi-terabyte disks is measured in days, and IOPS is still that of one disk. For most home users, 6-wide or 8-wide RAIDZ2 is the sweet spot.

Treating RAIDZ as a substitute for backup. Snapshots and replication to a separate system are what protect your data. A pool that survives a single drive failure does not survive a pool corruption, a controller failure that wipes labels, an rm -rf issued against the wrong dataset, or a fire.

A concrete starting recommendation

For a typical 4–8 bay home NAS focused on media, documents, and a handful of apps:

• Pool topology: One RAIDZ2 vdev, 6–8 drives wide.
• Drives: Matching capacity, ideally from at least two different manufacturing batches (to avoid simultaneous failure of disks that age in lockstep).
• Spare: Hot spare optional; cold spare on a shelf is more useful.
• Special vdev: Skip on day one. Add later if you find metadata operations are slow.

If your primary workload is VMs or iSCSI block storage, replace that recommendation with two or three 2-way mirror vdevs.

Next steps

• TrueNAS SCALE vs CORE in 2026: Which Should You Install? covers platform choice.
• TrueNAS Snapshot and Replication Strategy walks through the protection layer that sits on top of your pool design.
• ZFS Performance Tuning: ARC, Recordsize, and Compression covers the tunables that matter once the topology is fixed.

See also

• Docker homelab tutorials
• homelab firewall guide

FAQ

Can you convert a ZFS mirror to RAIDZ?

Not in place. TrueNAS’s pool documentation states that you cannot change the original data VDEV configuration, so mirror vdevs stay mirrors. The practical route is a new RAIDZ pool on separate disks, replication of every dataset to it, then retiring the old pool. Budget enough drive bays to run both at once.

How many disks do you need for RAIDZ1 in TrueNAS?

Three. TrueNAS documents minimums of three disks for RAIDZ1, four for RAIDZ2 and five for RAIDZ3. OpenZFS itself only requires one more disk than the parity level, but recommends 3 to 9 disks per RAIDZ group, and the TrueNAS ZFS primer advises against more than 12 disks in one vdev.

Is RAIDZ1 safe with large hard drives?

Not by TrueNAS’s own standard. The TrueNAS ZFS primer says RAIDZ1 is not recommended for drives over 1 TiB, because a resilver on large disks takes long and a second failure during it loses data. If you run RAIDZ1 on big drives anyway, keep a tested backup elsewhere, or use RAIDZ2 or mirrors instead.

Can you add a single disk to a ZFS mirror?

Yes, but it adds redundancy, not space. Attaching a disk to a two-way mirror makes a three-way mirror that survives two failures and still holds one disk’s worth of data. To grow capacity, add another mirror pair; OpenZFS makes that space immediately available to every dataset in the pool.