Backups
ZFS mirror basics: redundancy, usable capacity and what happens on disk failure
A ZFS mirror stores redundant copies of blocks across mirror members so the pool can continue when a member fails. It provides live redundancy plus ZFS checksumming/self-healing opportunities, but it still does not replace backups, snapshots, capacity monitoring, or a plan for replacing failed devices.
Understand mirror capacity and fault model
Usable capacity is roughly bounded by the smallest member in each mirror vdev; adding a second member does not double usable space. A two-way mirror normally tolerates one member failure in that vdev, but independent simultaneous faults can still destroy data.
Pool topology matters more than the total disk count.
Use checksums and scrubs
ZFS verifies checksums on reads and a scrub systematically reads allocated data so latent errors can be discovered while redundancy is available for repair. Scrubs are maintenance, not backups.
Monitor error counters and scrub completion explicitly; do not assume ZFS will alert someone automatically.
Plan replacement/resilver operations
Know device identifiers, hot-swap procedure, replacement size requirements, and how to attach/replace the failed member. Resilvering can take significant time and I/O depending on data size and pool health.
Avoid offlining the wrong healthy member during a degraded state.
Keep independent recovery copies
Deletion, ransomware, pool-wide hardware failure, operator mistakes, and site loss can affect the mirror as a unit. Use snapshots for local history and backups/offsite copies for separate recovery.
- Mirror is redundancy, not doubled capacity.
- Schedule/monitor scrubs.
- Document device replacement.
- Keep independent backups.