A snapshot protects against a mistake. It does not protect against a dead pool, a stolen laptop or a filesystem that corrupts itself. The value of ZFS here is that shipping a snapshot somewhere else is one command and transfers only the changed blocks.
1. Take them on a schedule
zfs snapshot -r tank/home@$(date -u +%Y%m%dT%H%M%SZ)
zfs list -t snapshot -o name,used,refer -s creation | tail -5Snapshots are nearly free at creation and cost only what diverges afterwards. Hourly for a week, daily for a month, monthly for a year is a policy that fits most workstations without thinking about it again.
2. Send incrementally
zfs send -I tank/home@monday tank/home@tuesday
| ssh backup-host zfs recv -F backup/home-I sends every intermediate snapshot between the two, so the receiving side keeps the same history rather than a single flattened state.
3. Verify the far end
ssh backup-host zfs list -t snapshot -o name,creation backup/home | tail -3
zpool status -v backupA replication job that has been failing quietly for three weeks looks exactly like one that is working, right up until you need it. Check the newest snapshot on the destination, not the exit code of the last run.
4. Scrub, and read the result
zpool scrub tankMonthly on spinning disks, quarterly on flash. The number that matters is the repaired count: non-zero once is a bad block handled correctly, non-zero repeatedly on the same device is a disk telling you it is finished.