It is a Friday evening and your team lead pings you: a finance VM has frozen, the datastore is almost full, and the cause is a snapshot somebody created three weeks ago and never removed. The first question in the chat is the one every fresher dreads: where is the backup? If your honest answer is "wait, isn’t the snapshot the backup?" then this part is for you. The two words get used as if they are interchangeable. They are not, and the gap between them is exactly where data gets lost.
The one sentence to memorise
A snapshot is a save-point that depends on the original VM. A backup is a copy that does not. That dependency is the whole story. Think of editing a long document. A snapshot is the Undo stack inside the open file: brilliant for stepping back a few changes, but if the file itself is deleted, every undo goes with it. A backup is the copy you saved to a USB drive and a cloud folder. Lose the laptop and the copy is still there. Both are useful. Only one survives the building burning down.
What a snapshot actually is
When you take a snapshot in vSphere, ESXi does not copy the whole virtual machine. It freezes the current virtual disk and makes it read-only, then creates a small new file called a delta disk, sometimes called a child or redo log. Every write the VM makes from that moment goes into the delta, not the original. The file is named with a pattern like vmname-000001.vmdk. If memory state was included, you also get a .vmsn file holding the contents of RAM at that instant, which is how a snapshot can restore a VM to a running state, not just a powered-off one.
Why the chain keeps growing
Take a second snapshot and the first delta is frozen too, and a new delta is created on top. Now you have a chain: base, delta 1, delta 2. To read a single block of data, the host may have to walk the whole chain to find the most recent version. That is why performance drops as the chain grows, and why a delta can swell to the size of the original disk if you leave it running while the VM is busy. The delta is a change log, not a tidy copy. It only makes sense sitting on top of everything below it.
What a backup actually is
A backup is a complete, independent copy of the VM, written somewhere other than the production datastore: a backup repository, a NAS, an object store, tape, or the cloud. It does not need the original VM to exist. You can delete the source, lose the whole host, and still rebuild the machine from the backup. Backup software such as Veeam, Nakivo or the tooling built into many platforms reads the VM, compresses and de-duplicates it, and stores it as its own restore point with its own retention rules. Crucially, a good backup lives on different hardware in a different place, so a single failure cannot take both the original and the copy.
Side by side
| Question | Snapshot | Backup |
|---|---|---|
| Where does it live? | Same datastore as the VM | Separate storage, ideally another site |
| Does it need the original? | Yes, useless without the base disk | No, fully independent |
| Good for | A quick undo during a patch or change | Disaster, deletion, ransomware, audits |
| How long to keep it | Hours, not days | Days to years, by policy |
| Performance cost | Grows the longer it runs | Brief load during the job, then none |
Why a snapshot is not a backup
Three concrete reasons, not vague ones. First, dependency: the delta files contain only the changes since the snapshot. Broadcom’s own guidance is blunt that if the base disks are deleted, the snapshot files alone cannot restore the machine. Second, location: the snapshot sits on the same datastore. If that storage fails, you lose the VM and its snapshot together. Third, growth: a snapshot left running keeps eating space until the datastore fills, and a full datastore can freeze every VM on it, not just the one with the snapshot. The official ceiling is 32 snapshots in a chain, but that is a hard limit, not advice. In practice keep two or three at most, and do not hold a single snapshot longer than about 72 hours.
Worked example: the math that fills a datastore
Say you have a 500 GB database VM on a datastore with 120 GB free. Before a risky upgrade you take a snapshot, the upgrade runs long, and you forget to remove it for two weeks. The database rewrites roughly 20 GB of data a day. Each rewritten block has to be kept in the delta because the base is frozen, so the delta grows by tens of GB per day.
By day six the delta has consumed the 120 GB of free space. The datastore hits zero, the VM pauses with a message asking you to provide more space, and any other VM on that datastore can stall too. Nothing was malicious. A single forgotten snapshot did it. A backup, sitting on separate storage, would never have touched the production datastore at all.
How they work together
Here is the part that surprises freshers: backup software uses snapshots, briefly. To copy a running VM without shutting it down, the backup tool asks ESXi to take a temporary snapshot. That freezes the disk so the backup can read a clean, unchanging copy of the base while the VM keeps writing to the delta. When the copy finishes, the backup tool removes the snapshot and the delta is merged back. So a snapshot is a tool the backup process borrows for a few minutes. It is the means, not the destination. The finished, independent restore point is the backup.
Real interview question
"A colleague says they do not need backups because they take daily snapshots. What do you tell them?"
Answer it like this: snapshots live on the same datastore as the VM and depend on the base disk, so if that storage fails or the VM is deleted, the snapshots go with it. They also grow over time and slow the VM down. A backup is an independent copy on separate storage that survives the loss of the original, which is the whole point of data protection. I would keep snapshots for short-term undo during changes and put a real backup job in place for recovery. Naming the dependency and the shared-storage risk is what the interviewer is listening for.
Try it yourself
In a free home lab (VMware Workstation, or nested ESXi), do this with a small test VM you do not care about:
1. Power on the VM and create a file on the desktop called before.txt. 2. Take a snapshot and name it test. 3. Delete before.txt and create after.txt. 4. Use Revert to the test snapshot.
How to check you got it right: after the revert, before.txt is back and after.txt is gone, because the snapshot returned the VM to its earlier state. Now look at the VM’s folder on disk and find the -000001.vmdk delta file. Delete the snapshot from the Snapshot Manager and watch that delta disappear as it merges. That is the whole lifecycle in five minutes, and it makes the dependency real.
My honest opinion: the 72-hour rule is too generous
The common advice, repeated everywhere including older VMware notes, is do not keep a snapshot longer than 24 to 72 hours. I think that number gives juniors the wrong mental model. It sounds like a snapshot is fine for three days, so people relax. On a busy production VM with a fast-changing database, a snapshot can do real damage in a single afternoon, long before 72 hours. My rule for newcomers is simpler and stricter: take the snapshot right before the change, and remove it the moment the change is confirmed working, ideally within the hour. If you genuinely need to keep a recovery point for days, that is not a snapshot job at all. That is what a backup is for. Treat the 72-hour figure as an absolute outer wall you should never get near, not a target.
FAQ
Can I restore a single file from a VMware snapshot?
Not directly. A snapshot reverts the whole VM to an earlier state. To pull back one file you would need backup software with file-level recovery, which mounts the backup and lets you browse it. This is another reason snapshots and backups are not the same job.
How many snapshots can a VM have?
The technical maximum in a chain is 32. That is a limit, not a recommendation. Keep it to two or three, and keep each one short-lived. Long chains slow the VM and make consolidation more likely to fail.
Does deleting a snapshot delete my data?
No. Deleting a snapshot merges its changes into the disk below and keeps your current data. The confusing word is Revert, which discards changes made since the snapshot. Delete keeps the present; Revert goes back in time. Read the dialog carefully.
Why did my VM freeze when the datastore filled up?
A running snapshot keeps growing its delta. When the datastore has no space left, the VM cannot write and pauses until you free space or extend the datastore. The fix is prevention: remove snapshots promptly and watch datastore free space.
Do I still need backups if I have vSphere HA?
Yes. HA restarts VMs when a host fails, but it does nothing for a deleted file, a corrupted database, or ransomware. HA is about availability; backup is about recovery. You want both. We covered HA in an earlier part of this series.
A backup you never tested is only a guess
The mistake that hurts most is not skipping backups. It is assuming a backup works because the job reported success. A backup is only proven when you have restored from it. Plenty of teams discover during a real outage that their restore points were corrupt, incomplete, or missing the one VM that mattered. Build the habit early: every so often, restore a backup to an isolated network and confirm the VM boots and the data is intact. A green tick in the backup console is a claim, not a guarantee.
Two numbers your seniors will quote
You will hear RPO and RTO constantly. RPO, recovery point objective, is how much data you can afford to lose, measured in time: a one-hour RPO means backups every hour, so the worst case is losing an hour of changes. RTO, recovery time objective, is how long you can be down while you restore. These two numbers decide how often you back up and how fast your storage needs to be. Snapshots play no part in either, because they are not a recovery copy. When a senior asks what your RPO is, they are really asking how recent your last independent backup is.
References
- Broadcom: Best practices for using VMware snapshots in the vSphere environment
- Broadcom: Overview of virtual machine snapshots in vSphere
- Broadcom: Consolidating and committing snapshots in VMware ESXi
About The Author
DrJha