One click freezes your virtual machine in time, and one click brings that moment back - including the time you installed something awful. Snapshots are the best reason to learn in VMs. They are also the most misunderstood feature in the product, because a snapshot feels like a backup and absolutely is not one.
A snapshot records the exact state of a VM - its disk, and optionally its memory and power state - so you can return to that moment later. Take one before a risky update and a bad outcome costs you ninety seconds. But snapshots live inside the same VM folder, on the same disk as the machine they protect, and old snapshot chains quietly eat space and performance. This page is the honest operating manual: when to take them, how to name them, when to delete them, and what to use instead for real backups.
When you take a snapshot, Workstation freezes the VM's current disk file and starts writing all new changes into a fresh difference file. Reverting throws the difference away and returns to the frozen state. This is why snapshots are instant, why each one grows as you keep working, and why long chains hurt: every read may have to look through several layers of difference files to assemble the disk. Understanding that one mechanism explains every rule on this page.
Take a snapshot immediately before anything you might regret: a major Windows update inside the guest, a new driver, unknown software from the internet, a registry experiment, a practice malware-analysis lesson in an isolated VM. Name it with the date and the reason - 2026-10-25 before driver test - because Snapshot 3 will mean nothing to you next week. If the experiment also must survive a power cut, a memory snapshot captures the running state too, at the cost of a file as big as the VM's RAM.
The moment the experiment succeeds and the VM has run happily for a while, delete the snapshot and let Workstation merge the changes into the base disk. Deleting is not losing the current state - it is committing it. The failure mode to avoid is the archaeological VM: months of snapshots, a host disk nearly full, and every disk read wading through layers. If you find such a VM, power it off, and consolidate during a quiet hour - merging a huge chain takes time and free space on the host.
Location: a backup lives somewhere else; a snapshot sits beside the VM it protects, so a dead host disk takes both. Completeness: a backup is a full copy; a snapshot is meaningless without its base disk and every layer between. Purpose: a snapshot answers undo the last hour; a backup answers the machine is gone. For a real backup, shut the VM down and copy its whole folder to another drive - or use Workstation's clone feature to a second location. That copy is a backup. The snapshot never was.
Each live snapshot makes guest disk writes a little slower and gives the host one more growing file to feed. On an SSD with a young snapshot you will feel nothing; on a nearly full hard disk with a month-old chain, you will feel everything. Keep an eye on the VM folder size versus the virtual disk size you declared - when the folder is double the disk's real contents, snapshot archaeology is usually why.
See snapshots used the right way in the lab workflow of the video series - take one, experiment, roll back in seconds.
Watch Full VideoThey are gone - reverting discards everything written since the snapshot, including documents and downloads, not just settings. Before reverting, copy anything you want to keep out of the VM or into a shared folder, because the time machine does not ask twice.
Far more than it should. There is no small hard limit that will save you, so discipline is the limit: one or two live snapshots for an active experiment is healthy; a chain you can no longer describe is a cleanup waiting to happen.
No. Deleting a snapshot merges its changes forward into the VM's current state - your VM keeps running exactly as it is now. What you lose is only the ability to travel back to that earlier moment.