Backups
Snapshots vs backups: know which failures each recovery method can survive
A snapshot records storage or filesystem state at a point in time, often quickly and efficiently. A backup is a recoverable copy designed to survive loss of the source. Snapshots can be excellent rollback tools, but snapshots stored only on the same platform are not automatically independent backups.
Identify snapshot scope and consistency
Determine whether the snapshot captures one filesystem, volume, entire VM, or storage dataset and what happens to attached/external data. Crash-consistent snapshots may need database recovery on boot; application-consistent snapshots coordinate writes before capture.
Read the specific platform semantics before depending on memory/state claims.
Map snapshot failure domain
If snapshots depend on the same storage pool, account, provider, or credentials as production, they may disappear in the same incident. Replicating/exporting them to an independent target changes that risk.
Do not count a local ZFS snapshot as an offsite copy.
Use snapshots for fast short-term rollback
Before upgrades or configuration changes, a snapshot can make rollback quick when discarding all post-snapshot writes is acceptable. For active transactional systems, define how newer writes are protected.
Set snapshot retention so old points do not silently consume all storage.
Pair with tested backups
Maintain independent versioned backups for source loss and verify restores onto a clean destination. Measure both snapshot rollback and full backup recovery.
- Know snapshot scope.
- Identify shared failure domain.
- Use for controlled rollback.
- Keep independent backups.