ZFS: mirror or RAID-Z? Planning your pool

Picking a ZFS layout is a bit like choosing a seat on a long flight: you can change it later, but nobody enjoys the process. Ten minutes of planning now save you a weekend of rebuilding.

The short answer

ZFS mirror or RAID-Z for a pool of 2 to 6 disks? With two disks, use a mirror. With more, it depends on the workload. Choose mirrors when random reads and writes dominate (virtual machines, databases) or when you want to grow two disks at a time. Choose RAID-Z2 when the pool mostly holds large files such as media and backups and you want any two disks to be allowed to fail. RAID-Z1 is the budget option for data you can replace or already have a second copy of. Whatever you pick, RAID is not a backup.

How it works

1. The words that matter: pool, vdev, redundancy. A ZFS pool is built from top-level vdevs (virtual devices). A vdev is a single disk, a mirror or a RAID-Z group [2]. The pool stripes data across all its top-level vdevs [2][4]. Redundancy lives inside a vdev, not across vdevs: if you lose a top-level vdev, you lose the pool [2]. So "two mirrors" means a pool with two vdevs, and "one RAID-Z2 of six disks" means a pool with one.
2. Mirror arithmetic. A mirror of N disks of size X holds X bytes and survives the loss of N-1 disks [4]. A two-way mirror gives you half the raw capacity and survives one failure.
3. RAID-Z arithmetic. A RAID-Z group of N disks of size X with P parity disks holds approximately (N-P) x X bytes and survives P failures [3][4]. RAID-Z1, Z2 and Z3 mean one, two or three parity disks [3]. The minimum is one more device than parity disks, and OpenZFS suggests 3 to 9 devices per group [3]. The VDEVs page lists at least 2, 3 and 4 disks for Z1, Z2 and Z3, with 3, 5 and 7 or more recommended [2]. "Approximately" is a real word here: with small records RAID-Z loses space to padding and parity, and with records no larger than the sector size its parity overhead equals that of a mirror [3]. The pool-wide numbers that zpool reports assume a fixed 128 KiB record and are a heuristic, not an exact measure [13]. The table below is our own calculation from these formulas, before padding and metadata, for disks of equal size.
4. Speed: what the layout changes. In a RAID-Z vdev, a write touches every disk of the stripe, so the worst case is the write IOPS (operations per second) of the slowest disk [3]. With the default 128 KiB records, a block usually spans all data disks, so every read costs one I/O on each of them, and random-read IOPS come out roughly like one disk per vdev. Streaming bandwidth still grows with the number of data disks [3]. The OpenZFS page says mirrors remain the better choice when random-read IOPS is the binding constraint [3]. Small blocks are also expensive on RAID-Z: for zvols (block devices that ZFS exports, for example as virtual machine disks), a small volblocksize makes RAID-Z space efficiency collapse toward mirror-level overhead [15]. Our reading: for big media files RAID-Z is a good fit, and for virtual machine disks mirrors are the simpler answer.
5. Failure and rebuild. When a disk fails, ZFS keeps serving data from the survivors of the same vdev, and after you replace the disk it resilvers (rebuilds) the new one [2]. Until that finishes, the vdev has less redundancy: a degraded RAID-Z1 or two-way mirror has none left. If ZFS cannot reconstruct a block, zpool status -v lists the damaged file and you restore it from a backup or snapshot [10][11]. zpool replace -s and zpool attach -s rebuild sequentially, which restores redundancy faster, and a scrub follows automatically because checksums are not verified during the rebuild. Sequential reconstruction is not supported for RAID-Z [10]. One 2026 guide puts the practical difference this way: a mirror rebuild reads one surviving disk, a RAID-Z rebuild reads all survivors [17]. Bigger disks mean a longer window, which is why both guides we read advise against RAID-Z1 for irreplaceable data on large disks [16][17]. We agree, but this is a risk judgement and not a law of nature.

The numbers for 2 to 6 disks

The mirror rows hide a trap. A pool of two mirrors survives two failures only when they hit different mirrors [16]. Of the 6 possible pairs of failed disks in a four-disk 2 x 2 pool, 2 are fatal [16]. With three mirrors of two disks, 3 of the 15 pairs are fatal (our count). RAID-Z2 has no fatal pair, because any two disks may fail.

Growing the pool later

There are three routes, and they differ a lot.

• Bigger disks. Replace the disks of a vdev one at a time with larger ones and wait for each resilver. The new space appears only after every disk in that mirror or RAID-Z group has been replaced. Set autoexpand=on, or run zpool online -e [1][13].
• Another vdev. zpool add appends a new top-level vdev. It takes new writes at once, but existing data is not rebalanced. Give it the same redundancy as the others, preview with zpool add -n, and think twice before forcing with -f, because that can leave the whole pool dependent on one disk [1]. If a pool has any RAID-Z or dRAID top-level vdev, no top-level vdev can ever be removed; the only fix is to rebuild the pool and restore the data [1].
• RAID-Z expansion. zpool attach pool raidz2-0 newdisk widens an existing RAID-Z vdev by one disk [1][5]. The feature arrived with OpenZFS 2.3.0, published on 14 Jan 2025 [8]. Version proof: in the OpenZFS feature flag table, retrieved on 25 Oct 2026, raidz_expansion is listed for 2.3.9, 2.4.4 and master, and not for 2.2.11 [7]. The pool feature is not read-only compatible [6], and according to the pull request that added it, the feature stays active for the life of the pool, so older releases cannot import a pool with an expanded vdev [9]. During the expansion, ZFS reads all allocated data and rewrites it across the wider group. The pool stays online, the expansion pauses if a disk fails, and a scrub starts at the end [5][9]. Fault tolerance does not change: a RAID-Z2 stays a RAID-Z2. Old blocks keep their old data-to-parity ratio, so reported free space can look slightly pessimistic [5]. The current man page points to zfs-rewrite(8) for rewriting old blocks with the new ratio, so check that your version ships it [5]. The new disk must be at least as large as the smallest existing one [5]. Some 2026 guides still call expansion "very limited" [17]. The OpenZFS pages describe the mechanism and its limits without calling it experimental. If your system runs an older ZFS, assume you cannot expand, and check with zpool version [18].

What the layout does not fix

• Backups. Redundancy covers a dead disk. It does not cover a deleted folder, ransomware, a mistyped zpool destroy or a fire. Snapshots live in the same pool and share its fate. Our articles on 3-2-1 backups and on restic and Borg are listed under Related pages.
• Controllers. OpenZFS advises against hardware RAID controllers, including single-disk RAID 0 arrays. Use an HBA (host bus adapter) that hands the raw disks to ZFS [11].
• Memory. OpenZFS strongly recommends ECC memory for enterprise use and says home users must weigh the cost against the protection [12].
• Sector size. ashift sets the sector size at creation. The default of 0 auto-detects it, a typical manual value is ashift=12 for 4 KiB sectors, and changing the pool property later does not modify an existing vdev [13]. On RAID-Z, ashift=12 can reduce capacity [12].
• Disk sizes. zpool create flags differently sized disks in one mirror or RAID-Z group as an error unless you force it [14]. The smallest disk sets the size [16]. Which drives to buy is a separate question, covered in our NAS drive article.
• Scrubs. A scrub reads every block and repairs damage where redundancy allows. Monthly is a common baseline for consumer disks [10].

Choosing by disk count

This part is our assessment, built on the documentation above and on the two 2026 guides [16][17].

• 2 disks: a mirror. RAID-Z1 would work with two disks but leaves you with the mirror's capacity and none of the benefit [2].
• 3 disks: RAID-Z1 if the data is replaceable or backed up, or a three-way mirror if you would rather have two survivable failures at a third of the capacity.
• 4 disks: the classic fork. Two mirrors for mixed or random loads and growth in pairs. RAID-Z2 for media, backups and large files where "any two disks" matters more than speed.
• 5 disks: RAID-Z2 (60 %). Mirrors need an even number of disks, so a fifth disk would sit idle as a spare.
• 6 disks: RAID-Z2 (about 67 %) for bulk data, three mirrors for random I/O.
• More than 6 disks: consider two groups instead of one wide one. OpenZFS suggests 3 to 9 devices per RAID-Z group [3].

A planning example

This is a frame for your own decision, not a report on our systems. About our homelab, only this is documented for this article: there is a QNAP NAS (as of 14 to 18 Oct 2026). We make no statement about its file system or pool layout.

Assume four equal disks for a media and backup pool. First, identify the disks by stable names instead of sda, sdb:

ls -l /dev/disk/by-id/ | grep -v part

Then preview both layouts. The option -n prints the layout and creates nothing [14]. Set ashift=12 only if your disks really use 4 KiB sectors; otherwise leave the default [13].

sudo zpool create -n -o ashift=12 tank \
  mirror /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B \
  mirror /dev/disk/by-id/DISK_C /dev/disk/by-id/DISK_D

sudo zpool create -n -o ashift=12 tank raidz2 \
  /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B \
  /dev/disk/by-id/DISK_C /dev/disk/by-id/DISK_D

After the real creation, check the pool and run a first scrub. If you chose RAID-Z and want to widen it later, check the version and the feature before you plan around it, then attach the new disk and watch the progress [5]:

zpool status tank
sudo zpool scrub tank
zpool version
zpool get feature@raidz_expansion tank
sudo zpool attach tank raidz2-0 /dev/disk/by-id/DISK_E
zpool status tank

A new pool enables all supported features by default. If you need to import it on older releases, restrict the features at creation with -o compatibility= [14]. Replacing a dead disk later looks like this: sudo zpool replace tank /dev/disk/by-id/DISK_OLD /dev/disk/by-id/DISK_NEW [1]. Try that once on a pool that does not matter yet.

Checklist

• Write down whether this pool holds the only copy of your data, and plan the backup before the layout.
• Decide the workload first: random I/O and virtual machines point to mirrors, large files and backups point to RAID-Z2.
• Check your ZFS version with zpool version before you count on RAID-Z expansion.
• List your disks by /dev/disk/by-id and preview the layout with zpool create -n before the real command.
• Compare the exact capacity of every disk in a group, because the smallest one sets the size.
• Choose an HBA or onboard SATA ports, and avoid a RAID controller in front of the disks.
• Plan the next growth step now: pairs of disks, bigger disks or a wider RAID-Z group.
• Check whether your system already runs a scrub timer, and run zpool status after the first scrub.
• Practice one disk replacement on a test pool, and restore one file from your backup.