Backups
ZFS snapshot planning: use retention and naming that make rollback understandable
ZFS snapshots are cheap point-in-time references to existing blocks until data changes. They are useful for rollback, accidental deletion recovery, replication, and short-term history, but they consume space as changed blocks remain referenced and share the source pool unless replicated elsewhere.
Choose snapshot points around change risk
Create snapshots before upgrades, configuration changes, deployments, bulk data operations, and on a schedule tied to recovery needs. Databases may need application-aware quiescing/dumps when a filesystem-consistent point is not enough.
Name snapshots predictably with timestamps/purpose so operators can select them under pressure.
Set retention from change rate
Snapshot “size” reflects referenced changed blocks and can grow unexpectedly when large files/databases are rewritten. Monitor dataset used/available space and per-snapshot referenced behavior.
Automate pruning carefully and protect special pre-change snapshots when required.
Understand rollback versus clone/restore
Rolling a dataset back can discard all newer snapshots/data depending on command/path. Cloning or copying selected files from a snapshot may be safer when only one mistake needs recovery.
Practice the exact recovery method in a non-production dataset.
Replicate for independent backup
Use ZFS send/receive or another backup path to copy recovery history to separate storage when source-pool loss must be survivable. A local snapshot alone is not offsite protection. Verify the replicated destination can be imported or restored without depending on the failed source pool.
- Snapshot before risky changes.
- Monitor retained changed blocks.
- Choose rollback/clone deliberately.
- Replicate outside source pool.