4-bay ZFS pool design: mirrors vs RAIDZ2 in 2026

For a four-drive ZFS pool, choose one four-wide RAIDZ2 vdev when the workload is mostly media, backups, and large sequential files; choose two two-drive mirror vdevs when VM, container, or database random I/O matters more. Both layouts provide about two drives’ raw capacity, but their failure behavior differs: RAIDZ2 survives any two drive failures, while two mirrors survive two failures only when one drive remains in each mirror. Avoid RAIDZ1 for the only copy of irreplaceable data. This guide was rechecked on August 2, 2026 against OpenZFS 2.4.2, current official layout documentation, a live 18TB retail snapshot, and a reproducible four-drive failure-matrix test. RAID is still not backup; keep a tested copy outside this pool.

The decision in one table

Four-drive topology	Approximate raw capacity before filesystem overhead	Failure tolerance	Best fit	Expansion path
2 × two-way mirror	50%	Any one drive; four of six possible two-drive failure pairs	VMs, containers, databases, mixed random I/O	Add another mirror vdev, or replace both members of one mirror with larger drives
1 × four-wide RAIDZ2	50%	Any one or any two drives	Media, backup targets, large files, stronger in-chassis fault tolerance	Replace all members with larger drives, or widen the RAIDZ vdev on supported OpenZFS versions
1 × four-wide RAIDZ1	75%	Any one drive; no two-drive pair	Replaceable bulk data with another verified copy	Replace all members, or widen the RAIDZ vdev; parity level remains RAIDZ1

These are topology guarantees, not predictions of which disks will fail. OpenZFS stripes the pool across top-level vdevs. Losing either complete mirror loses the pool, even if the other mirror is healthy. Conversely, RAIDZ2 keeps two parity columns within its one top-level vdev and therefore tolerates any two missing members.

Our recommendation changed from the original version of this guide, which said to “pick mirrors” almost universally. That advice hid the wrong-two-disks failure mode and was too broad. The correct choice starts with workload and recovery objective.

TopInsight test: enumerate every failure pair

We wrote a public Node.js test that enumerates every one- and two-drive failure combination for four labeled drives. Run it with:

node zfs-4-bay-failure-matrix-2026-08-02.mjs

Tested on August 2, 2026, with Windows 11 and Node.js 24.16.0. Results:

Topology	One-drive combinations surviving	Two-drive combinations surviving	Two-drive combinations fatal
2 × mirror (A+B, C+D)	4 / 4	4 / 6	2 / 6 (A+B or C+D)
RAIDZ1	4 / 4	0 / 6	6 / 6
RAIDZ2	4 / 4	6 / 6	0 / 6

This test verifies the combinatorics behind the decision table; it is not a disk benchmark and does not simulate correlated failures, unreadable sectors, or operator mistakes. We could not execute OpenZFS on this Windows host, so the commands below are taken from and cross-checked against the OpenZFS 2.4 documentation rather than presented as a local pool deployment.

Reproducible pool-create plan

Do not copy short names such as /dev/sda into a production create command. First map serial numbers to persistent /dev/disk/by-id/ paths, confirm every device twice, and keep the -n dry-run flag until the displayed topology is correct.

For two mirrors:

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

For four-wide RAIDZ2:

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

-n prints the proposed configuration without creating the pool. Remove it only after the by-id paths, topology, backups, and intended pool name have been reviewed. ashift=12 is the conservative 4 KiB-sector setting for typical modern HDDs; check the exact drive datasheet and platform defaults rather than assuming every future device is identical.

Once the pool exists, create datasets by workload instead of applying one record size everywhere:

sudo zfs create -o compression=zstd -o atime=off -o recordsize=1M tank/media
sudo zfs create -o compression=zstd -o atime=off -o recordsize=128K tank/documents

The 1 MiB media dataset favors large sequential files. The 128 KiB dataset is a safe general baseline. Databases and zvol-backed VMs need workload-specific testing: a filesystem’s recordsize and a zvol’s volblocksize are different controls, and blindly matching a database page size can worsen RAIDZ space efficiency or I/O amplification.

For the broader software choice, compare our TrueNAS Scale vs Core guide and Proxmox VE review. The topology decision is the same, but the UI and service defaults differ.

RAIDZ expansion is real, with limits

The old article incorrectly said RAIDZ vdevs could not be expanded. Current OpenZFS can widen an existing RAIDZ group by attaching a device:

sudo zpool attach tank raidz2-0 /dev/disk/by-id/DISK_E

OpenZFS reads allocated data and rewrites it across the wider group while maintaining the existing redundancy level. A RAIDZ2 stays RAIDZ2; adding a disk does not turn RAIDZ1 into RAIDZ2. Old blocks retain their original data-to-parity ratio, new blocks use the wider ratio, and OpenZFS starts a scrub after expansion. Expansion also consumes time and I/O, so it is an upgrade path—not a substitute for capacity planning or backup.

Mirrors remain simpler to grow in pairs. zpool add -n tank mirror ... previews a new top-level mirror. Existing data is not automatically rebalanced, and forcing a non-redundant vdev into a redundant pool can create a pool-wide single point of failure.

Drive choice and the August 2026 price check

Check four things before brand preference: CMR recording, SATA versus SAS compatibility, sector format, and seller warranty. A SAS disk will not work on an ordinary SATA controller. The smallest member limits a mirror or RAIDZ group’s usable capacity, so near-matched labels are not enough—compare exact byte counts and sector format.

The previous article claimed new 18–20TB enterprise disks cost US$250–$320 and used units US$150–$200 without a dated listing. That range is no longer supportable. Our August 2, 2026 query of ServerPartDeals’ public 18TB catalog found one in-stock 18TB SATA option, a refurbished Toshiba MG09 at US$499 (US$27.72/TB). Four would cost US$1,996 before tax and shipping. Inventory is volatile, so treat this as a dated market snapshot, not a standing recommendation.

If buying recertified or refurbished drives, make the return window part of the burn-in plan. Record model, serial, firmware, power-on hours, SMART attributes, temperature, and a complete read/write surface test before adding data. A clean SMART snapshot does not guarantee future reliability, and drives do not always warn before failing. Our NAS drive buying guide covers warranty and test planning in more detail.

Compression, dedup, and special vdevs

Use compression. OpenZFS 2.2 and later defaults compression=on for new datasets, but an explicit compression=zstd keeps the intended algorithm visible. Measure CPU cost on low-power systems rather than calling it free.

Leave dedup off unless measurements prove duplicate blocks justify it and the system is sized from an actual dedup table estimate. The old “5 GB RAM per TB” rule is not a reliable capacity plan: DDT memory depends on unique block count and block size, not pool headline capacity. Compression usually captures much of the practical benefit at far lower operational cost.

Treat a special vdev as an advanced, workload-driven change—not a default four-bay shopping item. Metadata and selected small blocks stored there exist nowhere else, so losing an unprotected special vdev can lose the pool. If profiling shows a metadata bottleneck, use mirrored devices with appropriate endurance and preserve a tested pool backup. On a pool containing RAIDZ, a special vdev cannot later be removed.

For continuous copies to a second system, our tested TrueNAS + Syncthing guide explains why live sync, file versioning, ZFS snapshots, and off-pool backup solve different failure modes.

Operations after creation

1. Scrub on a measured schedule. OpenZFS calls monthly a common baseline for consumer disks and quarterly for enterprise disks. Check whether the distribution already installed a timer before creating a duplicate job.
2. Monitor pool and device health. Alert on zpool status, read/write/checksum error counters, SMART changes, and temperature. A checksum error can also point to cabling, controller, or memory problems.
3. Replace, then observe. Resilver duration depends on allocated data, device speed, fragmentation, and live workload; the original fixed “12–24 hours” or “three to seven days” claims were not reproducible and have been removed.
4. Test restore quarterly. Restore selected files and, periodically, an entire dataset to a separate location. Snapshots on the same pool do not survive pool loss.

Community perspective, reconciled

Recent r/zfs discussions do not support a universal winner. Operators favor mirrors for random I/O, incremental growth, and simpler replacement; others choose four-wide RAIDZ2 because any two drives may fail without losing the pool. The disagreement is mostly about workload and recovery time, not the underlying guarantees. The same split appears in independent videos: Hardware Haven emphasizes layout tradeoffs, Lawrence Systems demonstrates modern RAIDZ expansion, and Techno Tim shows the performance appeal—and operational stakes—of special vdevs.

The evidence-backed conclusion is therefore narrower than “mirrors are always best”: RAIDZ2 is the safer four-bay default for bulk storage; two mirrors are the performance-oriented default for random I/O. Pick the failure model you can explain, then prove the backup restore before trusting either one.