A snapshot feels like a backup. You click “Take Snapshot” before a risky change, the VM keeps running, and if things go wrong you roll back. So it’s easy to assume that a VM with a snapshot is protected. It isn’t — and that assumption has cost plenty of admins a weekend when a datastore filled up or a base disk went bad and the “backup” turned out to depend on the very thing that failed.
Snapshots are a genuinely useful tool. They’re just a tool for a different job than backup. This article explains what a snapshot actually is at the file level, why one that lingers becomes a liability, and where the line sits between a snapshot and a real backup you can restore from.
What a snapshot really is
When you take a snapshot, VMware doesn’t copy the VM. It freezes the original disk (the base VMDK) as read-only and creates a new delta disk, sometimes called a redo log or child disk. From that moment, every write the VM makes goes into the delta file. The base disk stops changing entirely.
Rolling back means throwing away the delta and reopening the frozen base. Keeping the change means merging the delta back into the base. Either way, the snapshot’s value comes entirely from its relationship to that base disk.
That relationship is the whole point. A delta disk on its own is meaningless — it’s a list of changes relative to a specific base. Lose or damage the base and the delta can restore nothing.
Why that makes it not a backup
Hold those two facts together — the delta depends on the base, and both live on the same datastore — and the reason snapshots fail as backups becomes obvious.
Snapshot vs backup
| Where it lives | Snapshot: same datastore as the VM. Backup: separate storage, ideally offsite. |
|---|---|
| Independence | Snapshot: needs the original base disk. Backup: stands on its own. |
| Survives datastore loss | Snapshot: no. Backup: yes. |
| Survives base-disk corruption | Snapshot: no. Backup: yes. |
| Intended lifespan | Snapshot: hours. Backup: days to years, per retention policy. |
| Protects against ransomware | Snapshot: weakly (often on the same volume). Backup: yes, if isolated. |
If the datastore dies, the base disk and its deltas die together. If ransomware encrypts the volume, it encrypts your snapshots along with everything else. A snapshot protects you against a change you made — a bad patch, a failed upgrade — and nothing more. It does not protect you against losing the storage the VM lives on, which is exactly what a backup is for.
The growth problem
Here’s where lingering snapshots turn from harmless to dangerous. A delta disk starts tiny and grows as the VM writes data. On a busy VM — a database, a mail server, anything with churn — it can grow fast. Left long enough, a single delta can approach the size of the original disk, and a chain of several can exceed it.
The danger is the shared datastore. The delta grows into the same free space everything else needs. When the datastore fills, the VM can no longer write its changes, so VMware stops or pauses it. A forgotten snapshot on one VM can take down others sharing that storage.
The performance cost
Even before a delta fills the disk, running on a snapshot costs speed. Reads may have to walk the chain to find the current version of a block, and writes always land in the growing delta rather than the optimized base layout. The longer the chain, the more overhead.
You feel this most on write-heavy workloads. A database VM left on a snapshot for days can slow noticeably, and the slowdown gets worse as the delta grows. It’s a quiet tax that people often blame on the application before they notice the snapshot that’s been sitting there since last Tuesday.
Consolidation and orphaned deltas
Deleting a snapshot in the UI doesn’t always clean up its files. VMware merges the delta back into the base — consolidation — and then removes the leftover delta files. If that merge is interrupted, or a backup tool removes a snapshot from its own side without telling vCenter, you end up with orphaned delta files still being written to even though the snapshot manager looks empty.
vSphere flags this with a warning:
Configuration Issues: Virtual machine disks consolidation is needed.When you see that, run consolidation from the VM’s Snapshots → Consolidate menu. It merges the stray deltas and frees the space. Two cautions:
- Consolidation is I/O-heavy. On a large, busy VM it can take a while and load the storage, so prefer a quiet window.
- It needs free space to work in. If the datastore is already nearly full because of the very deltas you’re trying to merge, you may have to free space elsewhere first.
The 72-hour rule of thumb
The widely used guideline: keep a snapshot no longer than 72 hours, and ideally only for as long as the task that needed it. It’s not a hard limit baked into the product — it’s hard-won operational advice. The longer a snapshot lives, the bigger its delta, the longer consolidation takes, and the higher the chance it fills a datastore before anyone notices.
Treat snapshots as a short-lived safety net for reversible operations:
Good snapshot habits
- Take a snapshot right before a patch, upgrade, or risky config change
- Name it with the reason and date so you know why it exists
- Commit or discard it as soon as the change is verified
- Never run a VM on a snapshot longer than a few days
- Alert on snapshot age and datastore free space, not just disk usage
- After any failed backup, check for leftover snapshots and consolidation warnings
What a real backup looks like
A real backup is an independent copy of the VM stored somewhere the VM doesn’t depend on. If the production datastore vanishes, the backup is untouched and can rebuild the VM on its own.
The practical standard is the 3-2-1 approach: keep 3 copies of the data, on 2 different types of media, with 1 copy offsite (or otherwise isolated). A snapshot on the same datastore satisfies none of those. A proper backup job — full or incremental, written to separate storage, with retention and a tested restore — satisfies all of them.
Backup tools do use snapshots, and that’s fine. They take a brief snapshot to copy a consistent disk image, then remove it. The snapshot is the mechanism, not the product. The product is the independent copy sitting on other storage.
If you’re weighing platforms and how each handles VM protection, the broader virtualization guides are a good next stop, and so is reading up on how snapshots compare to checkpoints on other hypervisors before you standardize a process.
Wrapping up
Snapshots and backups solve different problems. A snapshot is a fast, reversible bookmark that lets you undo a change — invaluable before patching, dangerous when forgotten. It lives on the same datastore, depends on the base disk, and grows until it either slows the VM or fills the storage and stops it.
A backup is an independent copy you can restore from when the storage itself is gone. Use snapshots for what they’re good at: take one before a risky change, verify, then commit or discard inside a day or two. For anything you’d be unable to recover from a real loss, you need an actual backup on separate storage — not a snapshot wearing a backup’s name.
