VMware ESXi and vSphere Cluster Management

VMware ESXi Virtual Machine Snapshots

Learn what VMware ESXi and vSphere VM snapshots capture, how reversion and snapshot trees work, and why snapshots are short-term rollback tools rather than backups.

A virtual machine snapshot is a point-in-time checkpoint of a VM. It preserves selected aspects of the VM at the moment you create it so you can later return the VM to that state.

Snapshots are most useful as short-term safety mechanisms before a controlled change, such as an operating system update, application installation, configuration change, or software test. They provide a convenient rollback point, but they are not a replacement for an independent backup.

What a VMware VM Snapshot Captures

A snapshot can preserve the VM configuration and the state of every virtual disk attached to the VM. You can also choose to capture the VM's memory state. Memory capture is optional and is different from preserving disk and configuration state.

State component — Included in snapshot — Explanation

Virtual machine settings — Yes — Configuration information associated with the VM is preserved with the checkpoint.

Power state — Yes — The snapshot records whether the VM was powered on, powered off, or suspended.

Virtual disk state — Yes — The snapshot preserves the state of all virtual disks attached to the VM at that point in time.

Memory state — Optional — When selected, the contents of VM memory are captured, allowing restoration closer to the VM's running condition.

Disk and configuration state versus memory state

Disk and configuration capture protects the VM's persistent virtual hardware and disk contents as they existed at the checkpoint. It does not by itself preserve everything that was in guest memory.

Capturing memory records the contents of the VM's virtual memory as well. This can make a restoration resemble returning to the same running session, but it requires additional storage and processing. Select it only when the running memory state is relevant to the test or recovery plan.

Before relying on a snapshot for an important application, consider application consistency and data protection requirements. A snapshot does not automatically guarantee that application data is in a transactionally consistent state. For suitable workloads, coordinate with application-aware protection or quiescing capabilities.

When to Use a Snapshot Before a Change

Create a snapshot immediately before a change that is potentially disruptive but temporary in scope. Common examples include:

Applying an operating system or application update.
Installing software with unknown or potentially harmful effects.
Changing guest operating system or application configuration.
Testing a driver, patch, script, or other software change.

Record why the snapshot exists, when it was created, what change it protects, and when it should be removed. A clear description helps another administrator identify the correct checkpoint and avoid retaining it indefinitely.

Example: software update rollback

Confirm that the VM has an appropriate backup or other protection for data that must not be lost.
Create a snapshot before applying the operating system or application update. Choose memory capture only if the running memory state is required.
Apply the update and test the application and important services.
If the test succeeds, keep the validated VM state and remove the temporary snapshot through supported vSphere tools.
If the test fails, confirm the intended snapshot and VM state, then revert to that checkpoint.

After reversion, files, installed applications, configuration changes, and disk writes made after the snapshot may no longer be available. Protect any required post-snapshot data before reverting.

Example: testing an application installation

Take a pre-installation snapshot, install and test the software, and then choose an outcome. If the software works, retain the current VM state and remove the temporary snapshot. If it causes problems, revert to the pre-installation checkpoint. Do not treat the snapshot as a permanent record of the VM.

Reverting to a Snapshot

Revert means returning a VM to the state represented by a selected snapshot. This restores the selected configuration and disk state, and it restores captured memory when the snapshot includes memory and the operation supports that state.

For example, if a VM has a snapshot from Monday and a user creates files and changes settings on Tuesday, reverting to the Monday snapshot can remove access to those Tuesday changes. Copy or back up required data before the rollback.

Safe reversion checklist

Read the snapshot name, description, creation time, and intended purpose.
Review the entire snapshot tree rather than selecting a checkpoint from memory.
Confirm which virtual disks and VM settings are affected.
Check whether memory state was captured and whether it is appropriate to restore it.
Verify application consistency and protect important current data.
Warn users and application owners that post-snapshot changes may be discarded.

Understanding the Snapshot Tree

Snapshots form a tree-like hierarchy, not merely an unrelated list of restore points. A snapshot has one parent snapshot: the checkpoint directly preceding it in that branch. It may also have one or more child snapshots created from it.

Multiple child snapshots create branches representing different sequences of VM changes. For example, an administrator might create a parent checkpoint, test one patch, and then create another child branch to test a different patch. Each branch can contain a different later disk and configuration history.

Base snapshot: Before maintenance
├── Child A: Tested update 1
│   └── Current state A
└── Child B: Tested update 2
    └── Current state B

In this example, reverting to Child A does not produce the same result as reverting to Child B. Select the snapshot that represents the desired configuration and change sequence. Review the tree before creating, reverting, removing, or consolidating snapshots.

Choosing a restore point in a branch

Start at the root or oldest relevant snapshot.
Follow the parent-child path that contains the desired test or configuration.
Compare names, descriptions, timestamps, and current-state indicators.
Confirm that the selected branch contains the changes you intend to keep or discard.

Snapshot Files and Storage Usage

A VM snapshot is represented by snapshot-related files in the VM's storage location. Conceptually, snapshot disk files, often called delta disks, record writes made after the checkpoint while the VM continues to access the earlier disk state through the disk chain.

As the VM continues to write data, delta disks can grow. Snapshot age, workload write rate, datastore capacity, and the number of snapshots in the chain all affect storage consumption. Monitor datastore space and snapshot age, especially for busy VMs.

Do not manually edit, rename, or delete snapshot files as a recovery method. Manage snapshots through supported vSphere management interfaces. Manual file changes can break the disk chain or make the VM difficult to recover.

Snapshot Lifecycle and Administration

A sensible lifecycle is:

Create: Make a checkpoint immediately before a defined change.
Change and validate: Perform the update, installation, or test and check the result.
Revert if needed: Return to the selected checkpoint when the change fails, after protecting required current data.
Remove or consolidate: When the snapshot is no longer needed, remove it or complete the required consolidation through vSphere.

Snapshot removal removes the checkpoint while retaining the VM's current state. It commits or merges the tracked snapshot changes into the active disk chain; it does not mean discarding the current VM state. Depending on the chain and workload, the operation can take time and use storage and I/O resources.

Snapshot consolidation combines outstanding snapshot-related disk changes when the environment reports that consolidation is required. Verify datastore capacity and VM status, then use the supported consolidation workflow.

Never leave a temporary snapshot in place longer than necessary. Track its reason, creation date, owner, expected removal point, and validation result. Long-lived snapshots increase chain complexity and can consume substantial datastore space.

Managing Snapshots in the vSphere Client

Use the supported vSphere management interface for snapshot operations:

Select the VM and open its snapshot management view.
Create a snapshot with a descriptive name and explanation. Choose whether to include memory when appropriate.
After the change, inspect the snapshot tree and current VM state.
Revert to the specifically selected snapshot if rollback is required.
After successful validation, remove the temporary snapshot.
If the environment reports that consolidation is needed, review datastore capacity and run the supported consolidation operation.

For related VM configuration work, see editing virtual machine settings. Datastore capacity and storage behavior are also important when monitoring snapshot growth.

Snapshots Are Not Backups

A snapshot is a short-term rollback checkpoint that remains part of the VM's storage chain. A backup is an independently managed copy intended to support recovery beyond temporary change testing.

Characteristic — Snapshot — Backup

Primary use — Quick rollback before a temporary change — Durable data protection and recovery

Retention expectation — Short term, with a defined removal point — Retained according to a recovery and retention policy

Rollback behavior — Returns the VM to a selected checkpoint and can discard later changes — Restores data from a separately managed copy

Protection against long-term loss — Limited; it remains dependent on the VM and its storage chain — Designed to provide recovery from deletion, corruption, or broader failures

Appropriate use case — Maintenance window, software test, or temporary configuration protection — Routine recovery, compliance, disaster recovery, and durable protection

Keeping a snapshot does not satisfy a normal backup requirement. Use an appropriate backup strategy for recovery from data loss, deletion, corruption, datastore failure, or other failures that could affect both the VM and its snapshot files.

Snapshot Operations and Their Effects

Operation — Purpose — Effect on post-snapshot changes — Administrative caution

Create snapshot — Establish a point-in-time rollback checkpoint — Later writes are tracked separately — Define the reason, owner, and removal time.

Revert to snapshot — Restore the selected VM state — Later disk and configuration changes can be lost — Confirm the exact tree location and protect required data first.

Remove snapshot — Retire a checkpoint after testing — Current VM state is retained while tracked changes are committed or merged — Allow for storage and I/O activity during the operation.

Consolidate snapshots — Combine outstanding snapshot-related disk changes — The VM's active state is preserved while the chain is consolidated — Verify capacity and use supported tooling.

Troubleshooting Common Snapshot Problems

Files created after a snapshot are missing after reversion

This usually means the effect of reversion was misunderstood. The selected checkpoint restores an earlier disk state, so files and other writes created afterward may no longer be accessible. Recover required files from a backup or another protected copy.

There are several snapshots and the correct one is unclear

Use the snapshot tree to identify the parent, child, branch, timestamp, and description associated with the desired restore point. Reverting to another branch can discard a different set of subsequent changes. Do not select a snapshot based only on its name.

Snapshots are being used as routine backups

This confuses short-term rollback with long-term protection. Establish and verify a separate backup process. A snapshot remains tied to the VM's storage environment and is not an independently managed recovery copy.

Snapshot-related storage use keeps increasing

The VM is probably continuing to generate writes while a snapshot is active, causing its delta disk to grow. Review snapshot age and workload activity, check datastore capacity, and remove or consolidate the snapshot through supported tooling when it is no longer needed. See snapshot consolidation for the related administration task.

Removal reports that consolidation is required

Outstanding snapshot-related disk changes may remain after a snapshot operation. Verify available datastore capacity and the VM's status, then run the supported consolidation workflow. Avoid manually manipulating snapshot files.

Exam-Relevant Notes

A snapshot is a point-in-time checkpoint, not a complete independent backup.
Snapshots can preserve VM settings, power state, and virtual disk state; memory capture is optional.
Reverting can destroy access to disk writes, installed software, files, and configuration changes made after the checkpoint.
Snapshots form parent-child trees and can have multiple branches.
Snapshot removal retains the current VM state by committing or merging tracked changes.
Delta-disk growth and long snapshot chains require storage monitoring and timely cleanup.
Use supported vSphere tools rather than manually editing snapshot-related files.