Synopsis #
A ZFS snapshot is a read-only point-in-time view of a dataset. It provides a convenient local recovery point, but it is not a backup while it remains on the same pool. Replication with zfs send and zfs receive copies the snapshot to a separate pool or host.
This procedure uses tank/data as the source dataset and backup/tank-data as a new destination dataset. Replace both names deliberately. A mistaken destination can overwrite or expose data when later commands are added to the workflow.
Confirm the source and destination #
List pools, the source dataset, and available space before creating anything:
$ zpool list
$ zfs list -o name,used,available,mountpoint tank/data
$ zfs list -o name,used,available,mountpoint backup
The destination pool should be physically and operationally independent of the source. A second dataset on the same pool is another copy, not protection from pool failure, theft, or loss of the host.
Confirm that the intended destination dataset does not already exist:
$ zfs list backup/tank-data
The expected result for this first full receive is dataset does not exist. If it exists, stop and decide whether it is an earlier replica that requires an incremental stream.
Create and inspect a snapshot #
Use a name that identifies the purpose or date:
# zfs snapshot tank/data@manual-2026-08-13
$ zfs list -t snapshot tank/data@manual-2026-08-13
The snapshot initially consumes little additional space. Its USED value grows as blocks referenced by the snapshot are changed or deleted in the live dataset.
When the dataset’s snapdir property permits it, individual files can be inspected through the hidden .zfs/snapshot directory:
$ ls /tank/data/.zfs/snapshot/manual-2026-08-13/
Copying an individual file out of this directory is safer than rolling back the entire dataset. A rollback can discard newer data and is outside this procedure.
Estimate the stream #
Use a dry run to estimate the full stream before transmitting it:
# zfs send -nPv tank/data@manual-2026-08-13
Compare the estimate with the free space on the destination. Compression and pool layout can make source usage and destination allocation differ.
Receive the full snapshot #
Pipe the stream into a new, unmounted destination dataset:
# zfs send -v tank/data@manual-2026-08-13 | zfs receive -u backup/tank-data
-u leaves the received dataset unmounted. This prevents a backup copy from unexpectedly appearing over an existing path. Assign and verify a mount point separately if the replica must be browsed.
Confirm that both sides contain the named snapshot:
$ zfs list -t snapshot tank/data@manual-2026-08-13
$ zfs list -t snapshot backup/tank-data@manual-2026-08-13
A successful command and matching snapshot names confirm that ZFS accepted the stream. They do not replace periodic restore tests, pool health checks, or off-site copies.
Send the next snapshot incrementally #
Create a second snapshot after data changes:
# zfs snapshot tank/data@manual-2026-08-20
# zfs send -nPv -i tank/data@manual-2026-08-13 tank/data@manual-2026-08-20
The first snapshot must still exist on both sides. Send only the difference between the two snapshots:
# zfs send -v -i tank/data@manual-2026-08-13 tank/data@manual-2026-08-20 | zfs receive -u backup/tank-data
Do not destroy the common snapshot until the next incremental receive has completed and the retention policy permits its removal. A missing common snapshot breaks that incremental chain.
Make the copy a backup #
A maintained backup process also needs:
- automatic snapshots with an explicit retention policy;
- a destination on another failure domain, preferably another host or site;
- monitoring for failed or interrupted sends;
- capacity alerts on both pools;
- regular scrubs and review of
zpool status; - restore tests that verify files, permissions, and application consistency.
Databases and other stateful services may require application-aware quiescing or snapshot hooks. A crash-consistent filesystem snapshot does not guarantee application-level consistency.