A few years back, I was testing a shady-looking WordPress plugin for a Fiverr client. He wanted to know if it was safe before installing it on his live site. Smart move on his part — dumb move on mine, because I ran it directly on my main testing VM without thinking twice.
The plugin trashed the database. Corrupted tables, broken admin panel, the whole mess.
I wasn't worried, though. I'd taken a snapshot right before installing it. Two clicks, and the VM was back exactly where it was ten minutes earlier — like the plugin install never happened.
That's the moment I actually understood what snapshots are for. Not backups. Not magic. Just a really clever bit of bookkeeping that lets you rewind time on a virtual machine.
So What Is a VM Snapshot, Really?
A snapshot is basically a saved "state" of your virtual machine at one exact moment — its disk contents, its memory (if you choose), and its configuration.
Here's the part that trips people up: a snapshot doesn't copy your entire virtual disk somewhere else. That would be slow and would eat huge amounts of storage every time you took one.
Instead, the hypervisor (VirtualBox, VMware Workstation, Hyper-V, whatever you're using) freezes the current virtual disk file and starts writing all new changes to a separate, temporary disk file layered on top of it.
Think of it like putting a sheet of tracing paper over a drawing. The original drawing (your VM's disk at the time of the snapshot) doesn't get touched. Every new change you make happens on the tracing paper on top. If you want to go back, you just remove the tracing paper.
That "tracing paper" file has different names depending on the platform:
- VMware calls it a delta disk (.vmdk with a snapshot suffix)
- VirtualBox calls it a differencing disk
- Hyper-V calls it an AVHDX file
Same idea, different label.
Also Read: How a Virtual Machine Gets Its CPU Time
What Actually Gets Saved
When you hit "Take Snapshot," you're usually given a choice, and this is where a lot of beginners get confused:
Disk state — this is always included. It's the point-in-time copy-on-write layer I just described.
Memory state (RAM) — optional, but this is the part that feels like magic. If you check this box, the hypervisor also dumps the entire contents of the VM's RAM to a file. That means when you restore the snapshot later, the VM doesn't just boot up fresh — it wakes up mid-task, exactly where it was. Open applications, unsaved documents, everything.
I use this constantly when I'm testing software that needs a specific setup — like a database connection already open, or a form half-filled. Restoring the snapshot puts me right back in that exact working state instead of me manually recreating it every time.
The trade-off? Memory snapshots are slower to create and take up more disk space, since RAM dumps for a VM with 8GB or 16GB allocated aren't small.
Real Talk: The Mistake That Taught Me the Most
Around 2023, I was running a long-term test VM for a client's cybersecurity homelab setup. I took snapshots constantly — before every config change, every package install, every firewall rule tweak. Good habit, right?
Except I never deleted the old ones.
Three months in, that VM had over 40 snapshots stacked on top of each other. Performance was crawling. Disk reads that should've taken milliseconds were taking seconds. I genuinely thought VMware Workstation was broken.
It wasn't broken. It was just doing exactly what I told it to.
Here's why: every snapshot layer adds another lookup step. When the VM needs to read a piece of data, it has to check the newest layer first, and if that data isn't there, it checks the layer below, and the layer below that — all the way down the chain until it finds the original disk. With 40 layers, every single read was climbing down a 40-rung ladder.
The fix was simple but scary: merge (delete) the old snapshots I didn't need, keeping only the recent ones that actually mattered. VMware calls this "consolidating." VirtualBox does it automatically when you delete a snapshot in the middle of the chain — it merges the changes downward.
Lesson learned: snapshots are a short-term convenience, not a long-term filing system.
How to Take a Snapshot (Step-by-Step)
Different tools, same basic flow. Here's roughly how it goes in VirtualBox, since that's what I recommend to clients just starting out:
- Power the VM on or leave it running (you can snapshot a running or powered-off VM — a running one lets you capture memory state too)
- Right-click the VM in the VirtualBox Manager and choose Take Snapshot
- Give it a name that actually means something — "Before plugin install" beats "Snapshot 3" every time. Future-you will thank present-you.
- Click OK and let it process (usually a few seconds, longer if RAM is included)
- To go back, right-click the VM, choose Restore Snapshot, and pick the one you want
VMware Workstation's process is nearly identical — it's under VM > Snapshot > Take Snapshot, with the same restore option sitting right next to it.
Hyper-V users will find "Checkpoints" in the same right-click menu on a VM — Microsoft just uses different naming, but it's the identical concept underneath.
Also Read: The Invisible Layer That Turns One Server Into Many
Snapshots vs. Backups (People Mix These Up Constantly)
This is genuinely the most common misunderstanding I run into with clients, so let's be blunt about it:
A snapshot lives on the same physical disk as your VM. If your hard drive dies, corrupts, or the host machine gets wiped, your snapshot dies with it. It was never a separate copy — it's just extra layers sitting on the same storage.
A real backup is a completely separate copy, ideally stored somewhere else entirely (external drive, cloud storage, a NAS, whatever).
I always tell clients: snapshots protect you from your own mistakes during testing. Backups protect you from hardware failure and disasters. You genuinely need both if you're doing anything that matters.
Common Mistakes I See (And Made Myself)
Leaving snapshots running forever — as covered above, this slowly kills performance and eats disk space. Set a habit of cleaning up old ones once you've confirmed a change works.
Treating a snapshot as a backup — it isn't. If the underlying storage fails, the snapshot is gone too.
Snapshotting a VM mid-installation — if you catch a snapshot while software is actively writing files (like halfway through a Windows update), restoring it later can leave the OS in an inconsistent state. Snapshot before you start a risky change, not during one.
Forgetting which snapshot is which — "Snapshot 1," "Snapshot 2," "Snapshot 2 (copy)" tells you nothing six weeks later. Name them with context every time.
Running production workloads on a VM buried under old snapshots — I've seen this on client servers. Someone took a snapshot "just in case" two years ago and forgot about it. That single old layer was quietly slowing down every disk operation the whole time.
Final Thoughts
Once you actually understand that a snapshot is just a layered difference file sitting on top of your original disk — not a full copy, not a backup, not something to hoard indefinitely — the whole feature stops feeling mysterious and starts feeling like a genuinely useful safety net.
I use snapshots almost every time I test something risky for a client now, whether that's a sketchy plugin, an OS update, or a config change I'm not 100% sure about. Take one before, test freely, restore if it breaks, delete it once you're confident the change is good.
That habit alone has saved me more headaches than I can count.
comments