ZFS Mirror vs RAIDZ
What Is the Difference Between a ZFS Mirror and RAIDZ?
A ZFS mirror stores redundant copies of data across two or more member devices, while RAIDZ distributes data and parity across multiple devices within a VDEV.
Mirrored VDEVs are often attractive when random I/O performance, recovery characteristics and incremental expansion are priorities. RAIDZ is often attractive when usable capacity, sequential throughput and parity-based redundancy are more important.
ZFS Mirror vs RAIDZ Comparison
| Characteristic | ZFS Mirror | RAIDZ |
|---|---|---|
| Redundancy Method | Multiple copies | Distributed parity |
| Typical Minimum | 2 devices | Varies by RAIDZ level |
| Random I/O | Generally stronger | Generally lower for common large-record layouts |
| Sequential Write Throughput | Good | Can scale well across data disks |
| Capacity Efficiency | Typically lower | Typically higher with wider VDEVs |
| Failure Protection | Depends on mirror width | 1, 2 or 3 devices per VDEV depending on RAIDZ level |
| Expansion | Straightforward by adding mirrored VDEVs | Add VDEVs or use supported RAIDZ expansion |
| Common Fit | VMs, databases, random I/O | File storage, backup, media, capacity-oriented workloads |
RAIDZ Can Provide Greater Capacity Efficiency
A two-way mirror effectively stores two copies of the data, making approximately half of the equal-drive raw capacity available before filesystem and operational overhead. Wider RAIDZ VDEVs can dedicate a smaller percentage of total raw capacity to redundancy.
N represents the number of equal-size devices and X represents device size. RAIDZ formulas are simplified raw-capacity estimates. Actual usable capacity varies with block geometry, metadata, allocation, formatting and operational free space.
8 × 12 TB Drives: Mirror vs RAIDZ
Eight 12 TB drives provide 96 TB of total raw device capacity. Different VDEV layouts use that raw capacity differently.
| Layout | Raw Capacity | Simplified Usable Raw Capacity | Redundancy |
|---|---|---|---|
| 4 × 2-Way Mirrors | 96 TB | ≈ 48 TB | 1 failure per mirror; multiple failures may survive if they occur in different mirrors |
| 8-Drive RAIDZ1 | 96 TB | ≈ 84 TB | 1 device |
| 8-Drive RAIDZ2 | 96 TB | ≈ 72 TB | 2 devices |
| 8-Drive RAIDZ3 | 96 TB | ≈ 60 TB | 3 devices |
Capacity figures are simplified raw estimates and do not represent final formatted or recommended usable capacity.
Mirror and RAIDZ Failure Behavior Is Different
Redundancy in ZFS exists inside each top-level VDEV. The pool depends on every top-level data VDEV remaining available. This makes the placement of failures just as important as the total number of failed devices.
Mirrors Generally Have the Advantage for Random IOPS
When small random I/O is the primary performance requirement, mirrored VDEVs are generally the stronger architecture. This makes mirrors particularly attractive for workloads involving many small, latency-sensitive operations.
RAIDZ Can Be Excellent for Sequential Storage
RAIDZ can provide strong sequential throughput because data is distributed across multiple data devices in the VDEV. This makes RAIDZ especially attractive for capacity-oriented workloads that primarily read or write larger sequential blocks.
Mirror vs RAIDZ Resilvering
When a failed device is replaced, ZFS resilvers the replacement by reconstructing the data it requires. The recovery mechanics differ between mirrors and RAIDZ because mirrors can obtain data from another complete copy while RAIDZ may reconstruct missing information from data and parity.
OpenZFS also supports sequential reconstruction for supported mirror replacement and attach operations. Sequential reconstruction is not supported for RAIDZ, making recovery characteristics another factor worth considering when selecting a topology.
Mirror vs RAIDZ Expansion
Storage growth should be considered before the pool is built. Both architectures can be expanded, but their expansion options and operational characteristics differ.
Add More Mirrored VDEVs
A mirror-based pool can grow by adding another mirrored top-level VDEV. This provides a straightforward way to add capacity and aggregate performance.
Add VDEVs or Expand RAIDZ
RAIDZ pools can grow by adding additional top-level VDEVs. Current OpenZFS also supports widening an existing RAIDZ VDEV through RAIDZ expansion.
Should You Use Mirrors or RAIDZ?
There is no universally superior ZFS VDEV layout. The appropriate topology depends on workload, capacity requirements, drive count, performance objectives, fault tolerance, expansion plans and recovery requirements.
- Random IOPS are important
- Running virtual machines
- Hosting transactional databases
- Latency matters more than maximum capacity
- Incremental expansion is valuable
- Faster recovery options are important
- Capacity efficiency is important
- Storing large files
- Sequential throughput matters
- Building backup or archive storage
- Large-capacity HDDs dominate the pool
- Parity-based multi-drive protection is desired
RAIDZ1, RAIDZ2 or RAIDZ3?
Choosing RAIDZ is only the first decision. You must also determine how much parity protection the VDEV requires.
Mirrors and RAIDZ Are Not Backups
Both mirrors and RAIDZ provide storage redundancy, but neither replaces an independent backup strategy. Redundant storage cannot independently protect against every form of data loss, including accidental deletion, malware, administrative errors and catastrophic loss of the storage system.
Important data should be protected by backups appropriate for the organization's recovery-point and recovery-time requirements.
ZFS Mirror vs RAIDZ FAQ
Is a ZFS mirror the same as RAIDZ?
No. Mirrors maintain redundant copies, while RAIDZ distributes data and parity across the VDEV.
Which has better random IOPS?
Mirrored VDEVs generally provide stronger small random I/O performance than RAIDZ VDEVs.
Which provides more usable capacity?
Wider RAIDZ layouts generally provide greater capacity efficiency than two-way mirrors because a smaller percentage of total raw capacity may be consumed by redundancy.
Are mirrors better for virtual machines?
Mirrored VDEVs are often attractive for VM storage because virtualized workloads commonly generate significant random I/O.
Is RAIDZ better for backup storage?
RAIDZ can be attractive for backup and archive workloads where capacity efficiency and sequential throughput are more important than maximum random IOPS.
Can a mirror survive two failed drives?
It depends on the topology. A two-way mirror cannot survive losing both of its members, but a pool containing multiple two-way mirrors may survive multiple failures when the failures occur in different mirrors.
Can RAIDZ be expanded?
Yes. Capacity can be added with additional top-level VDEVs, and current OpenZFS supports widening existing RAIDZ VDEVs through RAIDZ expansion.
Which is better: ZFS mirror or RAIDZ?
Neither is universally better. Mirrors often favor random I/O and flexible growth, while RAIDZ often favors capacity efficiency and sequential storage workloads.