A VM snapshot is a point-in-time capture of a virtual machine’s state, consisting of its virtual disks and configuration and, optionally, the contents of its memory and CPU state. In virtualization, a snapshot allows an administrator to revert the virtual machine to exactly that moment, for example after a failed update, and it serves as the consistent source from which most image-level backup tools copy data.
A VM snapshot is created by the hypervisor, not by the guest operating system, and it usually takes only seconds because no data is copied at creation. The price of that speed is that a snapshot depends on the original disk and grows as the virtual machine keeps writing.
How a VM snapshot is created
Most hypervisors implement snapshots with differencing disks, also called delta disks or overlays. At the moment of the snapshot, the original virtual disk is frozen as read-only, and a new, initially empty file is created to receive all subsequent writes.
Reads are served from the delta file if the block was changed after the snapshot and from the base disk otherwise. This technique is commonly described as redirect-on-write. Some storage systems use copy-on-write instead, copying the original block aside before overwriting it in place, which shifts the cost to the first write of each block.
Each further snapshot adds another layer, forming a snapshot chain. Reverting discards the newer layers, while deleting a snapshot requires merging its changes into the parent, a process called consolidation or commit that can generate heavy disk I/O. Snapshot trees are also possible: reverting to an older snapshot and continuing to work creates a new branch, and every branch keeps its own delta files until it is deleted.
Snapshot components and consistency levels
A snapshot can include different parts of the virtual machine state. What it includes determines how faithfully the machine returns to the captured moment and how long the operation takes.
| Snapshot type | What is captured | State after revert | Typical use |
|---|---|---|---|
| Crash-consistent | Disks only, no coordination with the guest | Like a sudden power loss | Quick rollback points |
| File-system-consistent | Disks after the guest flushes and freezes file systems | Clean file systems | General backups |
| Application-consistent | Disks after applications flush transactions | Databases start without recovery | Backups of database servers |
| Memory snapshot | Disks plus RAM and CPU state | Machine resumes running exactly | Testing and debugging |
Consistency beyond crash level requires guest integration tools. On Windows, the Volume Shadow Copy Service coordinates applications; on Linux, a guest agent can freeze file systems for the short moment of the snapshot. A memory snapshot takes longer and writes a file roughly as large as the configured RAM.
Implementations across hypervisors
The principle is the same everywhere, but each platform uses its own file formats and terminology. Knowing the names helps when reading storage directories or troubleshooting failed consolidations.
| Platform | Name used | Delta storage | Notable detail |
|---|---|---|---|
| VMware vSphere | Snapshot | Delta VMDK files | Chains are limited to 32 levels |
| Microsoft Hyper-V | Checkpoint | AVHDX files | Production checkpoints use VSS by default |
| KVM with QEMU | Internal or external snapshot | qcow2 internal or overlay files | Live merge through block commit |
| Proxmox VE | Snapshot | qcow2, LVM-thin or ZFS | Behavior depends on the storage type |
| Cloud IaaS platforms | Disk or volume snapshot | Provider block storage | Usually stored independently of the VM |
Cloud volume snapshots behave differently from hypervisor snapshots. Providers typically copy changed blocks to separate durable storage, so the snapshot survives deletion of the original volume and can be used to create new disks, much closer to a backup than a rollback layer.
VM snapshot compared with backups and clones
The most important rule in virtualization operations is that a local VM snapshot is not a backup. It lives on the same storage as the base disk and cannot be restored without it, so a storage failure destroys both.
| Copy type | Independent of original disk | Creation speed | Suitable retention |
|---|---|---|---|
| VM snapshot | No | Seconds | Hours to a few days |
| Full clone | Yes | Minutes to hours | Indefinite |
| Linked clone | No, shares the base disk | Seconds | Lab and VDI lifetimes |
| Image-level backup | Yes, stored elsewhere | Minutes to hours | Weeks to years |
Backup software uses snapshots as a temporary consistency point: it creates a snapshot, copies the frozen base disk to backup storage and then deletes the snapshot. When the deletion step fails, orphaned snapshots remain and silently grow.
Risks and good practice
Snapshots are safe for short periods, but they become a liability when left in place. Each layer adds read overhead and metadata lookups, and a delta disk can grow until it fills the datastore, which pauses every virtual machine stored there.
- Keep snapshots for hours or a few days, not weeks; vendor guidance for VMware commonly suggests no longer than about 72 hours.
- Keep chains short, ideally one or two levels, to limit performance impact.
- Plan consolidation during quiet hours, because merging large deltas stresses storage.
- Monitor for orphaned snapshots left by failed backup jobs.
- Avoid reverting domain controllers or replicated databases without understanding the effect on replication.
Reverting a machine also reverts its clock-dependent and network-visible state. Services that exchange data with other systems may then hold outdated tokens, sequence numbers or replication state, so rollbacks of distributed components need careful coordination.
In plain words
A VM snapshot is like a bookmark with an undo button for a whole computer that runs as software. Before making a risky change, an administrator sets the bookmark, and if the change goes wrong, the computer can be put back exactly as it was.
The bookmark does not copy everything; it only records what changes afterward. That makes it fast, but it is not a safe copy kept elsewhere, so it should be removed once the change is confirmed.
A real-world example
A systems administrator must apply a major version upgrade to an internal ticketing application running on a Linux virtual machine with a 200 GB disk. The upgrade includes database schema changes that cannot easily be undone.
At 19:00 the administrator stops the application, takes an application-consistent VM snapshot using the guest agent, and starts the upgrade. Halfway through, the schema migration fails because of an incompatible plugin, and the application no longer starts.
Reverting to the snapshot takes less than two minutes, and the service is back online in its previous state. After the plugin is updated, the upgrade succeeds the next evening; the administrator verifies the application for a day and then deletes the snapshot, letting the hypervisor consolidate about 18 GB of changes during the night.