RAIDZ2 vs Mirrors: Choose a Six-Disk ZFS Layout

With six equal 8 TB disks, one RAIDZ2 vdev provides about 32 TB nominal capacity, while three two-way mirror vdevs provide 24 TB. The failure boundaries differ too: RAIDZ2’s nominal protection covers any two failed disks; the mirrored pool needs at least one readable member in every pair.

That makes the choice more specific than “capacity versus speed.” You are choosing a layout for your workload, an acceptable pattern of failures and a way to grow the pool. This comparison keeps the same six disks throughout. Capacities and failure examples are calculated models, not hardware benchmarks or guarantees of successful recovery.

Compare one RAIDZ2 vdev with three mirror vdevs

Label the disks A, B, C, D, E and F. We will compare:

• RAIDZ2: one top-level data vdev containing all six disks, with distributed double parity.
• Mirrors: three top-level data vdevs, paired as A+B, C+D and E+F. Each pair stores two copies of its own data.

The mirrored pool distributes data across the three pairs. It does not store three independent copies of the whole pool. The OpenZFS VDEV explanation describes how a pool uses its top-level vdevs and why redundancy belongs inside each vdev. If both members of a mirror pair are permanently lost, the pool is lost; the other pairs cannot reconstruct that vdev’s data.

“Three two-way mirrors” also differs from “one three-way mirror.” Keep the number of vdevs and the number of copies per vdev explicit in a plan.

Calculate nominal capacity with the same disk inputs

Using six equal 8 TB members and assuming no compression:

Raw capacity:          6 × 8 TB       = 48 TB
One RAIDZ2 vdev:       (6 − 2) × 8 TB = 32 TB nominal
Three two-way mirrors: 3 × 8 TB       = 24 TB nominal

The OpenZFS pool concepts manual documents mirror capacity and the approximate RAIDZ formula. RAIDZ2’s two-disk deduction is a parity capacity equivalent, rather than two dedicated parity disks.

The margin is a planning choice. These figures omit filesystem metadata, allocation effects and dataset constraints; they are not predictions of the exact AVAIL value on a real pool. The ZFS usable capacity guide explains those distinctions without treating a fixed percentage as universal ZFS overhead.

In the RAID / ZFS calculator, enter six disks, 8 TB per disk and the same reserve for both runs. Choose ZFS RAIDZ2 with one RAIDZ vdev, then compare ZFS two-way mirrors. The mirror mode models the three pairs from the total disk count. The separate RAID 1 mode represents one N-way mirror and would answer a different question.

Trace which disks fail, not just how many

The following table assumes the remaining disks and required data are readable. It models whole-disk failures and the redundancy of these two layouts:

There are 15 distinct ways to choose two failed disks from six. For the mirrored layout, three combinations lose a complete pair: A+B, C+D and E+F. The other 12 combinations leave a member in each pair. All 15 two-disk combinations are within the single RAIDZ2 vdev’s nominal double-parity protection.

These counts describe the topology. They are not failure probabilities: real failures need not be independent or equally likely, and the model does not include unreadable surviving data, controller or enclosure problems, operator error or loss of the host. It would be misleading to turn “12 out of 15 combinations” into an estimate of a particular pool’s reliability.

After A fails, B is the remaining copy in its mirror pair. Losing C is a different event from losing B. Keep that pairing visible in the inventory and replacement plan rather than relying on a pool-wide count of spare disks.

Match the layout to the workload you will actually run

For small random I/O, such as multiple busy VM disks, mirrored vdevs are a strong candidate to test. They provide several top-level vdevs over which the pool can distribute work. Large sequential transfers ask a different performance question. OpenZFS workload tuning discusses those geometry tradeoffs.

A drive count does not establish your application’s latency or throughput. Record the intended read/write mix, block sizes, concurrency and synchronous-write requirements, then compare on representative hardware and software. Keep cache state, pool occupancy and dataset or zvol settings consistent enough to understand the result. No fixed IOPS multiplier or rebuild duration is claimed here.

Small-block workloads also deserve a capacity check. RAIDZ allocation depends on block and sector geometry; the simple parity formula does not capture every padding effect. The OpenZFS RAIDZ explanation shows why a layout’s nominal capacity is not a universal effective capacity for every block size. Do not import a tuning value from an unrelated benchmark and assume it fixes both space efficiency and performance.

Distinguish adding capacity from adding another copy

Think about the next purchase before filling the current pool:

• Adding another two-way mirror vdev normally means adding a pair of disks; the new vdev contributes capacity to the pool. Existing data is not automatically redistributed evenly across it.
• Adding a third member to an existing two-way mirror increases the copies in that vdev. It does not turn the third disk into another disk’s worth of nominal data capacity.
• RAIDZ expansion exists on supporting releases. Widening the vdev does not change RAIDZ2 into a higher parity level, and old blocks can retain their original data-to-parity ratio.

The pool-layout documentation distinguishes these operations. Check the installed OpenZFS release and pool features before planning an expansion. The raidz_expansion feature description documents the relevant capability; this article is not a procedure for enabling features or changing a live pool.

Avoid the obsolete blanket claim that RAIDZ can never grow by adding a disk. Equally, an expanded RAIDZ2 vdev is not simply a mirror pool with different labels. Choose a supported growth path for the topology you actually have.

Make the choice explicit in a short worksheet

If your priority is more nominal capacity from these six disks and protection against any two whole-disk failures in this vdev, RAIDZ2 addresses those two requirements. If small random I/O and adding capacity in mirror pairs matter more, evaluate three two-way mirrors while accepting their pair-specific failure boundary. Neither choice replaces a workload test or a recoverable independent backup.

Resilver time depends on the actual pool and workload. Plan how you will identify a failed member, obtain a replacement and verify recovery without assigning a convenient universal number of hours. The backup and restore checklist covers the independent recovery copy; the backup transfer-time guide helps budget one part of getting the service back.