What is a ZFS Mirror?
What Is a ZFS Mirror?
A ZFS mirror is a VDEV in which each member device contains the data needed to provide redundant storage. The most common configuration is a two-way mirror consisting of two drives.
If one device in a two-way mirror fails, the remaining mirror member can continue providing the data. ZFS also supports mirrors containing more than two devices when additional redundancy is required.
ZFS Mirror Key Characteristics
Multiple Copies
Data is redundantly stored across the devices that make up the mirrored VDEV.
2 Drives
Two devices are the minimum required to create a conventional redundant ZFS mirror.
~50% With 2 Drives
A two-drive mirror provides approximately the capacity of one of its drives before filesystem overhead.
Strong Random I/O
Multiple mirrored VDEVs can provide strong random-I/O characteristics for suitable workloads.
How a Two-Way ZFS Mirror Stores Data
In a two-way mirrored VDEV, ZFS writes the data needed to maintain an equivalent copy on each mirror member. If either device becomes unavailable, the other device can continue serving the data.
Mirrors, VDEVs and the ZFS Pool
Understanding the relationship between drives, VDEVs and the storage pool is essential when planning mirrored ZFS storage. Individual drives form the mirror VDEV, while one or more top-level VDEVs provide storage to the zpool.
Using Multiple Mirrored VDEVs
Larger mirrored pools are commonly created from multiple mirror VDEVs rather than by placing every device into one large mirror.
ZFS Mirror Usable Capacity
With equal-size drives, the usable capacity of a mirror is approximately the capacity of one mirror member because the remaining device capacity is used to maintain redundant copies.
This is a simplified planning estimate. Actual filesystem capacity is lower because of drive reporting, ZFS metadata, reserved space and other storage overhead.
| Configuration | Raw Capacity | Approx. Data Capacity | Redundant Copy |
|---|---|---|---|
| 2 × 4 TB | 8 TB | ~4 TB | ~4 TB |
| 2 × 8 TB | 16 TB | ~8 TB | ~8 TB |
| 2 × 16 TB | 32 TB | ~16 TB | ~16 TB |
| 4 × 8 TB 2 mirrored VDEVs |
32 TB | ~16 TB | ~16 TB |
| 6 × 12 TB 3 mirrored VDEVs |
72 TB | ~36 TB | ~36 TB |
How Many Drives Can a ZFS Mirror Lose?
Fault tolerance is determined at the VDEV level. A two-way mirror can lose one member and continue operating. A three-way mirror can lose as many as two members, provided at least one valid mirror member remains available.
Fault Tolerance Is Per VDEV
A pool containing several two-way mirrors does not simply have a fixed number of drive failures that can occur anywhere. Failure tolerance depends on which drives fail.
For example, a pool with three two-way mirror VDEVs could potentially survive one failed drive in each mirror. However, losing both members of the same required mirror VDEV exceeds that mirror's redundancy even if every drive in the other mirrors remains healthy.
ZFS Mirror Performance
Mirrored VDEVs are commonly considered for workloads where I/O performance is a major design priority, particularly when multiple mirror VDEVs are combined in the same pool.
Replacing a Failed Mirror Drive
When one member of a two-way mirror fails, the mirror becomes degraded but the remaining member can continue providing data. The failed device should be replaced promptly to restore the intended redundancy.
ZFS then reconstructs the required data onto the replacement device through resilvering. Mirror resilvering can be an important consideration when comparing mirrored VDEVs with parity-based RAIDZ designs.
Expanding a Pool With Additional Mirrors
One practical characteristic of mirrored pool designs is that capacity can be increased by adding another complete top-level mirror VDEV to the pool.
Expansion strategy should be planned carefully because top-level VDEV configuration affects the pool's capacity, performance and fault domains.
Two-Way vs Three-Way ZFS Mirrors
| Configuration | Minimum Drives | Approx. Capacity Efficiency | Member Failures Tolerated |
|---|---|---|---|
| 2-Way Mirror | 2 | ~50% | 1 within the mirror |
| 3-Way Mirror | 3 | ~33% | Up to 2 within the mirror |
Is a ZFS Mirror the Same as RAID 1?
A two-way ZFS mirror and conventional RAID 1 share the basic concept of maintaining redundant data across two devices. However, they are not simply interchangeable names for the same storage architecture.
A ZFS mirror operates as part of ZFS and therefore participates in ZFS features such as end-to-end checksumming, copy-on-write, pooled storage, scrubbing and ZFS's integrated data-integrity mechanisms.
ZFS Mirror vs RAIDZ
Mirrors and RAIDZ represent different approaches to building redundant ZFS storage. Mirrors generally devote a larger percentage of raw capacity to redundancy but can offer advantages for random I/O, certain recovery scenarios and incremental expansion.
RAIDZ layouts can provide greater usable-capacity efficiency, particularly as VDEV width increases, while RAIDZ2 and RAIDZ3 provide multiple parity levels. The correct choice depends on workload, drive count, capacity requirements, performance targets, fault tolerance and expansion plans.
When Does a ZFS Mirror Make Sense?
ZFS Mirror Advantages and Tradeoffs
- Simple redundancy model
- Strong random-I/O potential
- Fast access to redundant copies
- Additional mirror VDEVs can expand a pool
- Two-way and higher-order mirrors are possible
- Well suited to many performance-oriented workloads
- Two-way mirrors devote roughly half of raw capacity to redundancy
- Three-way mirrors require even more redundant capacity
- Failure tolerance must be understood per VDEV
- Mirrors may provide less usable capacity than RAIDZ for the same raw drive count
- Pool topology should be planned before deployment
A ZFS Mirror Is Not a Backup
Mirroring provides redundancy, but redundancy is not the same as an independent backup. A mirror can protect against specified device failures, but changes to the live filesystem are reflected through the mirrored storage.
Important data should still be protected by an appropriate backup strategy designed around the organization's recovery objectives and failure scenarios.
ZFS Mirror FAQ
What is a ZFS mirror?
A ZFS mirror is a VDEV that maintains redundant data across two or more member devices.
How many drives does a ZFS mirror require?
A conventional redundant mirror requires at least two devices. ZFS can also use mirrors with additional members.
How much capacity does a two-drive mirror provide?
With equal-size drives, approximately the capacity of one drive is available before filesystem and storage overhead.
Can a ZFS mirror survive a drive failure?
A two-way mirror can tolerate one failed member as long as the other member remains available and valid.
Can ZFS use three-way mirrors?
Yes. Additional mirror members can provide additional redundancy at the cost of usable-capacity efficiency.
Is a ZFS mirror the same as RAID 1?
They share the concept of mirrored data, but a ZFS mirror is integrated into the broader ZFS storage and data-integrity architecture.
Are ZFS mirrors faster than RAIDZ?
Mirror pools can provide advantages for some random-I/O workloads, but actual performance depends on the complete pool topology, hardware and workload.
Can I add another mirror to a ZFS pool?
A complete additional top-level mirror VDEV can be added to an appropriately designed pool to increase capacity.
What happens when a mirror drive is replaced?
ZFS reconstructs the required data onto the replacement device through a process called resilvering.
Is a ZFS mirror a backup?
No. Mirroring provides redundancy against device failure; it does not create an independent backup copy.