A Snapshot Is Not a Backup

Snapshots are one of the most useful buttons in a virtualization stack, and one of the most misused. Before I patch a VM, change a config, or install something invasive, I take a snapshot — it’s the fastest “undo” in existence, and if the change goes sideways I revert and it’s like it never happened. That’s exactly what a snapshot is for. What it is not is a backup, and treating a pile of snapshots as your backup strategy is how you discover, at the worst possible moment, that your safety net was attached to the same branch that just broke.

What a snapshot actually is

A VM snapshot captures a point in time by freezing the current disk and writing all subsequent changes to a delta. Revert, and it throws the delta away and returns you to the frozen state. It’s fast to take, fast to revert, and perfect as a short-lived rollback anchor: the “I’m about to do something I might regret” undo. The key words are short-lived and same place — the snapshot lives right next to the VM it’s protecting, on the same storage, in the same system.

A snapshot is an undo button, not an insurance policy. It’s brilliant for the next ten minutes and dangerous as a plan for next year.

Same failure domain means it can’t save you from the real disasters

The defining weakness is that a snapshot shares a failure domain with the thing it’s supposed to protect. It’s on the same datastore, managed by the same host, dependent on the same storage array. So the disasters a backup exists to survive are exactly the ones a snapshot can’t:

• The datastore fails or corrupts — and takes the VM and its snapshots with it.
• The host or storage array dies — the snapshot dies with it.
• Ransomware or a bad actor reaches the storage — the snapshots are right there too.

A backup earns its name by being independent: a separate copy, on separate storage, ideally in a separate location, that survives the loss of the original. A snapshot has none of that independence, so it protects against “I made a change I want to undo” and nothing larger. It’s the same reasoning as being able to restore in another failure domain — a copy that dies with the original was never really a copy.

Snapshots get more expensive the longer they live

The other trap is that snapshots aren’t free to keep around, and the cost grows with age. Because every change since the snapshot accumulates in that delta, a long-lived snapshot’s delta grows and grows — eating disk and, on many platforms, quietly dragging down the VM’s I/O performance because reads and writes now thread through the delta chain. A snapshot you meant to keep “just in case” for six months isn’t a backup; it’s a slow, growing performance tax that also happens to provide no disaster protection. Chains of forgotten snapshots are a classic way to fill a datastore and slow a fleet at the same time.

That’s why the discipline with snapshots is to take them deliberately and delete them promptly once the risky change is proven good. They’re meant to be temporary. A backup, by contrast, is meant to be retained — different tool, different lifetime.

Use each for what it’s actually good at

The two aren’t competitors; they’re different jobs:

• Snapshot → short-term, same-place rollback for a specific risky action. Take it right before the change, revert if it fails, delete it once you’re confident. Minutes to hours, not months.
• Backup → durable, independent, restorable copy for data loss, corruption, and disaster. Separate storage, retained on a schedule, and — the part people skip — actually tested by restoring it, because a backup you’ve never restored is a rumor, and one you don’t monitor can be silently failing.

The mistake isn’t using snapshots. It’s using them as backups — leaning on “well, there’s a snapshot” for protection that a snapshot structurally cannot provide.

Ask what it survives

The one-question test I apply now: what does this copy survive? A snapshot survives a bad change on a healthy system. A backup survives the system itself being gone. If the thing I’m worried about is “my change broke it,” a snapshot is the right, fast tool. If the thing I’m worried about is “the storage died, the site’s gone, the data’s corrupted,” only an independent backup answers that, and no number of snapshots adds up to one. Take the snapshot before the patch — then make sure you also have a real backup for the day the snapshot can’t help. If you’ve been saved by a snapshot, or burned by mistaking one for a backup, I’d like to hear the story.