Signal / 024 — ZFS replication is a backup path, not a backup policy

Explainer: A snapshot feels like a backup right up until the pool holding both the live data and the snapshot disappears.

OpenZFS provides a powerful replication path: zfs send serializes a snapshot into a stream, and zfs receive reconstructs it as a dataset. After an initial full transfer, incremental sends can move only the changes between snapshots. For a home lab, that can make frequent replication practical even when the second system is slower or connected over a limited link.

Replication can copy mistakes

A synchronized copy is not automatically an independent backup. Deletion, corruption introduced above the filesystem layer, bad retention rules, or an overly powerful replication account can travel down the same path. Keep the destination administratively separated, retain multiple recovery points, and avoid giving the sending host more control than it needs.

OpenZFS also warns that storing send streams as ordinary files is a poor long-term archive format: damage to the stream can make it unreceivable. A received dataset is checksummed and can be scrubbed. The project’s scrub documentation notes another boundary: without redundant devices, ZFS can detect damaged data but cannot repair it.

Test the return trip

Opinion: The valuable command is not the one that sends the snapshot. It is the restore you have rehearsed. Periodically receive a backup into an isolated test dataset, open representative files, and record how long recovery takes. Keep another copy off the primary machine—and preferably outside the same physical failure zone.

Snapshots provide time travel. Replication provides another copy. A backup policy supplies the distance, retention, verification, and human procedure that make either one dependable.

AI-assisted summary: This explainer was drafted with AI assistance and reviewed against official OpenZFS documentation. Commands should be tested on non-production data first.