RAID-Z

RAID 5 has one famous bad morning: the power cut in the middle of a write. RAID-Z was built so that morning never happens.

The short answer

RAID-Z is the parity layout of ZFS. It comes in three levels, raidz1, raidz2 and raidz3, which survive one, two or three failed disks per vdev [1][2]. Unlike RAID 5 and 6 it avoids the "write hole", where data and parity disagree after a power loss [1][2][5]. Our assessment: for a NAS with several large disks, RAID-Z2 is the sensible default. If random reads matter more than capacity, mirrors fit better. Neither replaces a backup.

How it works

1. Levels and capacity. A group of N disks of size X with P parity disks holds about (N-P)×X bytes and survives P failures. The minimum is one disk more than the parity count, and the documentation recommends 3 to 9 disks per group [1][2]. The vdev guide lists raidz1 with at least 2 disks (3 or more recommended), raidz2 with at least 3 (5 or more) and raidz3 with at least 4 (7 or more) [3].
2. No write hole. Data and parity are striped across the group, but not always in a fixed stripe width [1]. Because ZFS uses copy-on-write, the pool switches to a new consistent state in one atomic step, which is why it has no equivalent of the RAID 5 write hole [5].
3. Space efficiency depends on block size. The OpenZFS RAIDZ page works through an example: a three-disk raidz1 with ashift=12 and a 4K record uses 50 percent of its space for data, and with a 128K record about 66 percent. A wider group is more efficient [2].
4. Speed. In the worst case a RAID-Z vdev writes at the IOPS of its slowest disk, because every stripe part must land on every disk. With the default 128 KiB record, each read touches every data disk, so random-read IOPS come out roughly like a single disk. The documentation adds that mirrors remain the better choice when random-read IOPS are the limit [2].
5. Growing the pool. zpool add appends a new top-level vdev, but existing data is not rebalanced [4]. Since OpenZFS 2.3.0 (published 14 Jan 2025) you can also widen a RAID-Z vdev by attaching a disk [6]. The expansion reads and rewrites all data, keeps redundancy, and does not change the fault tolerance: a RAID-Z2 stays a RAID-Z2. Old blocks keep their old data-to-parity ratio. The pool then carries the raidz_expansion feature flag, so older software versions cannot import it [4][7].
6. No way back. A pool with any RAID-Z top-level vdev cannot shrink. No top-level vdev can ever be removed again, not even a disk added by mistake [4].

A homelab example

We have not recorded RAID-Z on any Bytearium system (inventory as of 14 to 16 Oct 2026), so this is a generic calculation. Six 8 TB disks in raidz2 hold roughly (6-2)×8 = 32 TB of the 48 TB raw capacity, before overhead, and survive any two failures [1]:

sudo zpool create tank raidz2 /dev/disk/by-id/DISK_1 /dev/disk/by-id/DISK_2 \
  /dev/disk/by-id/DISK_3 /dev/disk/by-id/DISK_4 /dev/disk/by-id/DISK_5 /dev/disk/by-id/DISK_6
sudo zpool attach tank raidz2-0 /dev/disk/by-id/DISK_7   # widen the vdev later

The raidz2 type and the zpool attach form are the documented syntax [1][4]. Watch zpool status while the expansion runs [4]. If a disk fails in the middle, the expansion pauses until the vdev is healthy again [7].

Checklist

• Choose the parity level for the failure you can live with: one, two or three disks per vdev.
• Keep the group within the recommended width of 3 to 9 disks [1].
• Compare mirrors and RAID-Z for your workload before you buy disks [2].
• Run zpool add -n before adding anything to a pool with a RAID-Z vdev [4].
• Check your ZFS version supports raidz_expansion before you plan to widen a vdev [6][7].
• Replace a failed disk at once and watch the resilver finish.
• Keep a backup outside the pool.