Snapshots are not backups
A snapshot feels like a backup — it captures the state of things and you can roll back to it. But it lives on the same disk, dies with it, and a surprising number of data-loss stories start with someone trusting one as if it were a real backup.
Snapshots are genuinely useful. They are also the thing people most often mistake for a backup — right up until the disk they live on fails and takes both the data and its “backup” with it. Knowing the difference is the difference between a quick recovery and a disaster.
What a snapshot is
A snapshot records the state of a filesystem or volume at a moment, so you can roll back to it. On ZFS or LVM it is nearly instant and cheap. It is perfect for “I am about to do something risky” — take a snapshot, make the change, roll back if it goes wrong.
Why it is not a backup
- It lives on the same storage — the disk fails, the snapshot fails with it
- It is tied to that machine — the server is lost, the snapshots are lost
- Ransomware or a bad actor with access can delete it as easily as the live data
A backup, by contrast, is a copy somewhere else — another machine, another site, immutable storage. That separation is the entire point. See backups that actually restore and backups that survive ransomware.
Use both, for different jobs
Snapshots are for fast, local, short-term rollback — before an upgrade, between deploys. Backups are for surviving the loss of the machine. They are not competitors; a good setup has both, and never confuses one for the other. See deploying without downtime.
Snapshots can feed backups
The clean pattern: take a snapshot to get a consistent point-in-time view, then back up from the snapshot to somewhere else. That gives you a crash-consistent backup without pausing the live workload — the snapshot is the method, the offsite copy is the protection.
Watch snapshots that linger
Old snapshots are not free forever — they hold on to every block that has changed since, so a forgotten snapshot can quietly consume a lot of space and, on some systems, slow writes. Keep them short-lived; prune them on a schedule. See a disk that fills up.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base