Synopsis #
ZFS combines filesystem and volume-management operations, so a short command can cross a large recovery boundary. Begin by identifying whether the task concerns local history, an independent copy, pool integrity, capacity, or hardware replacement. Those are different controls.
This page routes common operational questions to focused procedures. It does not replace the complete ZFS reference in the official documentation.
Choose the task #
| Goal | Procedure | Important boundary |
|---|---|---|
| Select ZFS or UFS and design datasets | Choose a filesystem and storage layout | Layout follows recovery and policy, not directory fashion. |
| Create a recovery point and copy it to another pool | Snapshot and replicate a ZFS dataset | A snapshot on its source pool is not an independent backup. |
| Recover selected files | Restore files from a ZFS snapshot | Copy and validate files instead of rolling back the whole dataset. |
| Send incremental snapshots to another host | Replicate a ZFS dataset over SSH | Restrict remote receive authority and retain a common snapshot. |
| Select a maintained replication scheduler | Choose ZFS backup automation | Prove one manual transfer and restore before delegating retention. |
| Check integrity | Read ZFS pool health and run a scrub | A scrub verifies existing copies; it is not a backup. |
| Replace one failed member of a simple mirror | Replace a failed device in a ZFS mirror | Prove topology and physical identity before writing the replacement. |
Collect evidence first #
These read-only commands establish the starting point for most pool work:
$ zpool status -P -v
$ zpool list
$ zfs list -o name,used,available,mountpoint
$ zfs list -t snapshot -o name,creation,used -s creation
Preserve the output before clearing errors, exporting a pool, detaching a device, destroying a snapshot, or changing mount points. A provider name without topology and physical identity is not enough evidence for a destructive command.
Keep four protections separate #
- Redundancy can preserve availability after specific device failures.
- Snapshots preserve earlier references within the same pool.
- Replication places a point-in-time dataset copy on another pool or host.
- Restore testing proves that the copy can satisfy the application and ownership requirements.
One control does not silently become another. A mirrored pool with many snapshots can still be lost with the host, and a successful replication job can still produce an unusable application state.
Escalate when the topology differs #
The local device-replacement guide deliberately covers only a simple surviving mirror. RAIDZ, dRAID, special and deduplication vdevs, encrypted raw sends, pool feature upgrades, corrective receive, and damaged metadata require the exact current manual-page procedure and a topology-specific recovery plan.
When a command would remove the last known copy, destroy an incremental base, or change pool topology, preserve an independent backup and obtain a second review before proceeding.