VMware ESXi and vSphere Cluster Management

Virtual Machine Snapshots in VMware vSphere and ESXi

Learn how VMware vSphere and ESXi snapshots capture VM state, use snapshot trees, revert safely, manage storage, and avoid treating snapshots as backups.

A VMware virtual machine snapshot is a point-in-time checkpoint: a captured reference state from a specific moment. It lets an administrator preserve a known-good condition before a temporary or risky change and later return the virtual machine to that earlier state.

Snapshots are useful operational tools, but they are not backups. A snapshot is normally a short-term rollback mechanism managed with vSphere, whereas a backup is an independent recovery copy retained according to a recovery policy.

What a VMware VM Snapshot Does

A snapshot records the VM state needed to return the VM to a selected point in time. That state can include the VM's settings, power state, virtual disk state, and, optionally, memory contents.

The snapshot does not usually duplicate every byte of every virtual disk at the instant it is created. Instead, VMware preserves the existing disk state and records subsequent writes in snapshot-related delta disk layers. This makes creation relatively quick, but the delta data can grow as the VM continues to write data.

A common workflow is:

Verify that a current backup exists and that the datastore has sufficient free space.
Create a clearly named snapshot before a planned change.
Apply and test the change.
Keep the snapshot only while validation is in progress.
Delete the snapshot after successful validation, or revert to it if the change must be abandoned and the resulting data loss is approved.

What State Does a Snapshot Capture?

The exact result depends on the selected options and the VM's power state. A snapshot with memory is different from one without memory.

VM settings: Included. The virtual machine configuration, such as virtual hardware and related settings, is associated with the snapshot. Reverting can return relevant configuration state to the captured point.

Power state: Included. The snapshot records whether the VM was powered on, powered off, or suspended. The resulting behavior depends on the state captured and the selected revert operation.

Virtual disk state: Included. The snapshot preserves the state of the VM's attached virtual disks at the snapshot point. Writes made afterward are tracked separately and can be discarded by a revert.

Memory state: Optional. For a powered-on VM, memory capture preserves the contents of the VM's memory so that a revert can more closely resume the running session. It can require additional storage and has different operational implications from a disk-only snapshot.

Snapshots With and Without Memory

A snapshot taken with memory captures the contents of a running VM's memory. This can preserve the in-progress execution state of applications and the guest operating system for temporary lab or troubleshooting work. It can also take more time and consume more storage.

A snapshot taken without memory does not preserve the running contents of RAM. The disk and configuration checkpoint remains, but reverting may require the VM to be powered on or restarted rather than resuming the exact running session. Any data that existed only in memory is not preserved.

Memory capture is therefore a deliberate choice, not a requirement for every snapshot. Consider the VM's power state, the purpose of the checkpoint, available capacity, guest behavior, and the expected recovery procedure.

Quiescing the Guest File System

Quiescing means coordinating the guest operating system and, where supported, applications so that writes are placed in a more consistent state when the snapshot is taken. Guest tools and application support affect whether quiescing is available and how effective it is.

Quiescing can improve file-system consistency, but it does not automatically turn a snapshot into an application-aware backup. Select the option only when it is applicable to the guest and appropriate for the workload.

How Snapshot Creation Works

Before creating a snapshot, plan it as a temporary operational safeguard. Check backup health, datastore free space, current VM workload, guest or application consistency requirements, and the change window.

When a snapshot is created, the existing virtual disk becomes the reference or base disk. A base disk is the original virtual disk on which later snapshot layers depend. New writes are directed to a delta disk, a file or disk layer that records changes made after the snapshot. Reads may involve the base disk and one or more delta layers.

Snapshot metadata, configuration state, and changed disk blocks are represented by files associated with the VM in its datastore. A datastore is the VMware storage location that holds VM files and snapshot-related files.

Do not manually delete, rename, or edit snapshot files from datastore storage. Use supported vSphere management operations. Manual changes can break disk relationships, cause data loss, or leave the VM requiring consolidation.

Snapshot Lifecycle Operations

Create snapshot: Establishes a checkpoint for a planned change. Later disk writes are tracked in delta layers. The key caution is to define an owner and cleanup date before creating it.

Revert to snapshot: Returns the VM to the selected snapshot. Disk and application changes made after that snapshot can be discarded. Confirm the exact snapshot and obtain approval for the expected data loss first.

Delete snapshot: Removes the selected snapshot while committing or merging its tracked changes as appropriate. Deletion is not the same as reverting; it normally preserves the current VM state while removing the checkpoint.

Delete all snapshots: Removes the snapshot hierarchy and commits or merges snapshot-related changes. This can create substantial storage and I/O activity, especially for large or long-lived trees.

Consolidate: Merges snapshot-related disk changes when snapshots are removed or leftover delta files must be resolved. Consolidation is a disk operation and requires adequate datastore capacity.

Revert Versus Delete

Reverting changes the VM's active state back to the selected point. All relevant disk and application changes made after that point may be lost. A rollback affects the state represented by the chosen snapshot, not merely one application or one configuration item.

Deleting removes the checkpoint and generally commits the changes represented by its delta disks into the continuing disk chain. It is used for cleanup after validation, not to undo the change that was tested.

Always confirm the intended snapshot by reviewing its name, description, timestamp, parent relationship, and current-state indicator. Treat revert and deletion as potentially disruptive or destructive operations.

Typical vSphere Client Workflow

Select the target virtual machine.
Open the VM's snapshot management actions.
Create a snapshot with a descriptive name and reason.
Choose memory capture and guest quiescing options according to the VM state, guest support, and consistency requirement.
Use Snapshot Manager to inspect the tree, identify the current state, revert, delete, or consolidate snapshots.
Monitor the task and datastore capacity until disk merging or consolidation completes.

PowerCLI Examples

PowerCLI can automate common operations, but commands do not replace capacity checks, approval, or post-operation validation.

New-Snapshot -VM <VMName> -Name <SnapshotName> -Description <Reason>

Get-VM <VMName> | Get-Snapshot

Set-VM -VM <VMName> -Snapshot <SnapshotName> -Confirm:$false

Get-VM <VMName> | Get-Snapshot | Remove-Snapshot -Confirm:$false

Before running a revert or removal command, explicitly verify the VM name, selected snapshot, application impact, backup status, and authorization. Review the result in vSphere and confirm that the intended snapshot was affected.

Snapshot Trees and Branches

Snapshots can form a snapshot tree, which is the parent-child hierarchy of snapshots and branches. A parent snapshot is the earlier snapshot from which another snapshot descends. A child snapshot is a later snapshot that descends from a parent.

A simple sequence might contain snapshot A followed by snapshot B. However, the tree can branch:

Create snapshot A.
Make a change and create snapshot B.
Revert to snapshot A.
Make a different change and create snapshot C.

Snapshots B and C are separate child branches under A. They represent different lines of change from the same earlier point. The current VM state is shown by the current-state marker in snapshot management, not simply by the newest timestamp.

Deep or long-lived trees create administrative risk. They are harder to interpret, consume more datastore space, complicate cleanup, and can increase the time and I/O required to merge disk changes. Use meaningful names and descriptions, and remove obsolete branches through supported tools.

Rollback Consequences

Suppose a snapshot is taken before an operating system update. After the snapshot, an administrator installs the update, changes configuration, creates files, and users write new data. Reverting to the snapshot can discard all of those post-snapshot changes, not just the update.

Before reverting a production VM, communicate:

Which snapshot will be selected.
Which applications and users will be affected.
Which disk data, configuration changes, and application activity may be lost.
How long the maintenance and validation window is expected to last.
How required newer data will be preserved or recovered.

Obtain business approval where required. If newer data must be retained, use an independent backup or another approved recovery source before reverting.

Appropriate Snapshot Use Cases

Software patching: A snapshot provides a short-term rollback point before an operating system or application update. Delete it after successful testing; revert only after confirming that later data loss is acceptable.

Configuration testing: A checkpoint allows controlled evaluation of service, registry, network, or application configuration changes. Clean up once the desired configuration is confirmed.

Driver or agent installation: A snapshot can protect a test or maintenance VM while installing drivers, monitoring agents, or security software. Validate boot, networking, monitoring, and application behavior before cleanup.

Application evaluation: A nonproduction test VM can be checkpointed before installing software that might destabilize the guest. Revert when the experiment is complete if the changes are not intended to remain.

Long-running production protection: This is a poor use. A snapshot retained for an extended period can grow rapidly, degrade performance, consume datastore capacity, and provide a false sense of recovery protection.

Snapshots Versus Backups

Snapshots are not a replacement for backups. A snapshot commonly remains dependent on the same VM storage system and datastore. A backup is an independent recovery copy retained according to a recovery policy and typically stored separately from the running VM.

Primary purpose: A snapshot supports short-term rollback during a controlled change. A backup supports recovery from data loss, corruption, deletion, or a broader failure.

Expected retention period: A snapshot should normally be short-lived and have an explicit expiry plan. Backups are retained according to recovery-point, compliance, and business requirements.

Storage independence: A snapshot is closely tied to the VM and its storage chain. A backup should provide an independent recovery copy.

Recovery use case: A snapshot is useful for reversing a recent, known change. A backup is used to restore data or a VM after a storage, host, guest, or operational failure.

Effect of datastore problems: A datastore failure or capacity problem can affect both the VM and its snapshots. An independent backup can remain available when the original datastore cannot be used.

Need for regular testing: Both require operational validation, but backup restore procedures must be tested as part of the recovery plan. A snapshot that can be reverted does not prove that backup recovery works.

Relying on snapshots alone creates recovery, capacity, and operational risk. Maintain tested backup and restore procedures even when snapshots are used for maintenance rollback.

Storage and Performance Considerations

Post-snapshot changes consume datastore space. Write-intensive VMs can grow delta disks rapidly, particularly when a snapshot remains active for a long time. Multiple snapshots and deep chains add further management and performance complexity.

Potential effects include increased I/O overhead, longer snapshot removal or consolidation tasks, reduced VM performance, and a datastore approaching capacity. A datastore with insufficient free space can put both snapshot operations and normal VM operation at risk.

Monitor datastore free space before and during snapshot use.
Alert on active snapshots, snapshot age, snapshot size, and datastore thresholds.
Consider the VM's write rate rather than relying only on the snapshot creation time.
Remove snapshots promptly after validation is complete.
Plan sufficient maintenance capacity for disk merging or consolidation.

Operational Safety and Governance

Use a naming convention that records the change purpose, date or maintenance window, and owner. For example, a name might identify an operating system patch, a maintenance window, and the responsible team. Put detailed context in the description, including the reason, expected expiry, affected application, and cleanup owner.

Every snapshot should have a cleanup plan before it is created. Define a maximum short retention period according to organizational policy and create alerts for age and datastore impact.

After a successful change, validate the guest operating system, application services, monitoring, integrations, and user-visible behavior. Delete the checkpoint only after validation is complete and no dependent operational process still requires the prior state.

Snapshots and VMware Mobility

VM state and storage choices affect mobility operations such as vMotion, VMware technology for moving a running VM, and Enhanced vMotion, a VMware mobility capability that can involve broader compute and storage migration considerations.

Active snapshots can affect compatibility, available destination storage, migration duration, and the actions required after migration. Before migrating a VM with active snapshots, check VMware compatibility requirements, destination storage availability, VM configuration, and current VMware documentation. Do not assume that every migration path behaves identically for every snapshot layout.

Practical Example: Testing an Update

Verify a current, usable backup and confirm adequate datastore free space.
Create a snapshot named for the update, maintenance window, and owner.
Choose memory capture or guest quiescing only when the VM and test plan justify those options.
Install the operating system, application, driver, or agent update.
Test boot behavior, services, application functions, monitoring, and integrations.
If successful, delete the snapshot promptly and monitor the merging or consolidation task.
If unsuccessful, record the expected data loss, obtain approval, preserve required newer data, and revert to the selected snapshot.

The lesson is that a snapshot provides a short-term rollback point for a controlled change; it does not provide independent recovery.

Practical Example: Testing Potentially Harmful Software

Use a nonproduction test VM rather than a production system.
Create a clearly documented snapshot before the installation or experiment.
Run the test and review guest, application, network, and security behavior.
Revert when finished if the test changes should not be retained.
Remove the snapshot and return the test environment to its planned baseline.

A snapshot is useful for isolated experimentation, but it should not substitute for a clean test environment, malware-analysis controls, or backups.

Practical Example: Understanding Memory Capture

Compare two snapshots of a running lab VM. One includes memory and the other does not. The memory-inclusive snapshot can preserve more of the running session, including in-progress execution state, when reverted under the applicable conditions. The disk-only snapshot preserves the disk and configuration checkpoint but not the contents of RAM, so the VM may need to restart.

Memory capture can be useful for temporary lab work, but it can require additional storage and may be less desirable for routine maintenance. Select it based on the recovery objective rather than automatically enabling it.

Practical Example: Branching Snapshot Tree

Create snapshot A before a test. Make change one and create snapshot B. Revert to A, make a different change, and create snapshot C. The tree now contains A as the parent and B and C as separate child branches.

Use Snapshot Manager, names, timestamps, and change records to identify the current state and decide which branch is still needed. Retain only the branch required for the current objective and safely clean up obsolete snapshots.

Practical Example: Cleanup After Maintenance

Validate the VM, guest operating system, application, monitoring, and integrations.
Confirm that no dependent process still requires the previous state.
Delete the maintenance snapshot using vSphere management tools.
Monitor the disk-change merge or consolidation task rather than assuming deletion is instantaneous.
Confirm that datastore space is recovered and no snapshot or consolidation warning remains.

The snapshot lifecycle is incomplete until cleanup and post-operation validation are finished.

Troubleshooting Snapshot Problems

A Snapshot Is Consuming Significant Datastore Capacity

Likely causes include high write activity after creation, a snapshot retained longer than intended, multiple snapshots, or a deep tree.

Review snapshot age, tree depth, VM write activity, and datastore free space.
Check capacity alerts and related tasks.
Validate the VM state and remove unneeded snapshots through supported tools.
Plan adequate capacity and monitoring for consolidation.

Snapshot Deletion Takes a Long Time

Large delta files, high I/O while changes are merged, and multiple dependent snapshots can make deletion take a significant amount of time.

Avoid interrupting a legitimate deletion or consolidation task without understanding the impact. Monitor VM performance, datastore capacity, and task status. Reduce workload when appropriate and follow approved operational procedures.

The VM Reports That Disk Consolidation Is Needed

This can occur when snapshot-related delta files remain after an operation or when a previous removal did not fully merge the disk changes.

Confirm sufficient datastore free space.
Review active snapshots and current VM tasks.
Run the supported consolidation operation from vSphere management tools.
Investigate persistent failures through VMware logs and approved support procedures.

An Administrator Expects a Revert to Preserve Recent User Data

This usually indicates that a snapshot was misunderstood as a backup. Explain that disk and application changes made after the snapshot can be discarded. Confirm business approval before reverting and restore required newer data from an independent backup or another approved recovery source when available.

A Snapshot Tree Contains Unexpected Branches

Repeated reverts followed by new snapshot creation can create branches. Poor naming and missing lifecycle documentation make them difficult to interpret.

Map parent-child relationships, identify the current-state marker, and compare names, timestamps, and change records. Retain only the branch needed for the current operational objective and safely clean up obsolete snapshots.

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.
Quiescing coordinates guest writes to improve consistency when supported and appropriate.
Post-snapshot writes are tracked in delta disk layers and consume datastore capacity.
Revert discards later state; delete removes the checkpoint while generally preserving current changes through merging.
Snapshot trees have parent-child relationships and can branch after a revert followed by new snapshot creation.
Long-lived or deep snapshot chains increase storage, performance, and administration risks.
Always verify the selected snapshot and expected data loss before a revert or destructive cleanup operation.
Use supported vSphere tools rather than manually modifying snapshot files.
Check storage and compatibility before mobility operations such as vMotion or Enhanced vMotion.

For related study, review VMware virtual machine snapshots alongside backup strategy, consolidation, guest file-system consistency, datastore monitoring, cloning, templates, and PowerCLI automation.