VMware ESXi and vSphere Cluster Management

How to Revert a Virtual Machine to a Snapshot in VMware vSphere

Learn how to revert a VMware vSphere virtual machine to a snapshot, understand post-snapshot data loss, validate the VM afterward, and avoid common rollback mistakes.

Reverting a virtual machine (VM) to a snapshot returns it to the saved state represented by a selected snapshot. In VMware vSphere, administrators commonly use this operation to undo an unsuccessful software installation, operating-system update, configuration change, or testing activity.

This procedure is powerful because it changes the VM's active disk state. Files, applications, updates, and configuration changes made after the selected snapshot may no longer be present. Confirm the recovery point and understand the data-loss implications before accepting the revert confirmation.

What a Snapshot Revert Does

VMware ESXi is the hypervisor platform that hosts virtual machines. vSphere is the VMware management environment used to administer ESXi hosts and VMs. The vSphere Web Client is its browser-based administrative interface.

A snapshot is a point-in-time VM state that can be used as a short-term rollback point. It records the VM's virtual disk state and may also capture configuration and power-state information. A revert returns the VM to the state captured by a selected snapshot.

  • After a failed application installation, reverting can return a test VM to the state before the installation.
  • After an unsuccessful network or operating-system configuration change, reverting can restore the earlier VM configuration.
  • After a lab exercise, an instructor can revert a training VM to a baseline so that it is ready for the next student.

Revert, Delete, Create, and Restore Compared

ActionWhat it doesEffect on post-snapshot changesTypical use
Revert to snapshotReturns the VM to the state represented by a selected snapshot.Changes made after that snapshot may be removed from the VM's active disk state.Undoing a failed change or returning a lab or test VM to a known state.
Delete snapshotRemoves a snapshot and consolidates its changes into the current VM disk structure as required by the environment.Does not intentionally roll the VM back; the current VM state is normally retained.Ending a temporary recovery point according to a snapshot lifecycle policy.
Create snapshotCaptures a new point-in-time VM state.Does not remove existing changes; it establishes a new rollback point.Preparing for a controlled test or change window.
Restore from backupRecovers the VM or its data from an independent backup system.Depends on the backup recovery point and recovery method, not on the snapshot tree.Disaster recovery, long-term retention, or recovery when a snapshot is unsuitable.

Prerequisites and Access

Before beginning, confirm all of the following:

  • You can access vCenter Server or another vSphere environment that exposes snapshot management.
  • You have identified the correct VM in the vSphere inventory.
  • The VM has at least one snapshot.
  • Your account has permission to view and manage snapshots for that VM. The exact permission model depends on the vSphere roles assigned by your organization.
  • You understand which disk changes will be lost and have checked whether those changes are needed.
  • You have considered application, user, service, and stakeholder impact.
  • A current backup exists when the VM or its data is important.

For production systems, notify affected users and application owners before reverting. Identify any data created after the snapshot, including data stored in databases, file shares, external services, or other systems. A VM snapshot cannot recover data that was never captured in the VM's snapshot state.

Understand the Snapshot Tree

The Snapshot Manager is the vSphere interface for reviewing, selecting, reverting, and deleting snapshots. Its snapshot tree displays available restore points and their relationships.

A snapshot tree is a parent-child hierarchy. A child snapshot is created from a state represented by its parent or from a later point in the VM's activity. The tree's layout matters because selecting a snapshot in one branch may produce a different result from selecting a similarly named snapshot in another branch.

Identify the intended snapshot using several clues:

  • Name: Look for a meaningful label such as Before-app-update.
  • Date and time: Confirm that the timestamp is before the change you want to undo.
  • Description: Read notes describing the purpose, change window, or expected VM state.
  • Position in the tree: Confirm the parent and child relationships rather than relying only on the name.

Step-by-Step: Revert a VM in the vSphere Web Client

1. Locate the target VM

Sign in to the vSphere Web Client and locate the VM in the inventory. Verify its name, folder, cluster or host, and other identifying details. Do not rely on a similar name alone, especially in environments containing development, test, and production copies.

2. Open snapshot management

Open the VM's context menu or VM actions menu. Choose the option for managing snapshots, such as Manage Snapshots or the equivalent snapshot-management command shown by your vSphere version and permissions.

The Snapshot Manager opens and displays the snapshot hierarchy and available restore points. If the snapshot-management option is missing, check that you selected a VM rather than a host, folder, datastore, or another inventory object.

3. Select the intended snapshot

Click the snapshot that represents the desired recovery point. Check its name, timestamp, description, and position in the snapshot tree. Compare the timestamp with the installation, update, configuration change, or testing activity that you intend to undo.

Pause here and identify everything that may have changed after the snapshot. For a production VM, record important files, transactions, user activity, and external dependencies before proceeding.

4. Start the revert operation

With the correct snapshot selected, choose the Revert to action. vSphere displays a confirmation prompt because the operation can remove post-snapshot changes from the VM's active state.

Read the prompt carefully. Accept it only after confirming the VM, snapshot, timestamp, and expected data loss. If any detail is uncertain, cancel the prompt and investigate before continuing.

5. Wait for completion

Allow the operation to finish. Monitor the VM's task status or Recent Tasks area for progress, completion, or an error. Do not begin unrelated snapshot operations while a conflicting VM task is still running.

The resulting power state depends on the snapshot and environment behavior. A VM may remain powered on, or it may be restored to a previously captured power state. Treat the power state as something to verify rather than assume.

What Happens to the VM After Reverting

  • Virtual disk contents return to the selected snapshot's captured state.
  • Files created or changed after that snapshot may no longer be available in the active VM.
  • Applications installed after the snapshot may disappear or return to their earlier version.
  • Operating-system updates and configuration changes performed afterward may be undone.
  • Running applications, user sessions, and services can be interrupted or returned to an earlier state.
  • Data written outside the VM, such as to an external database or file service, may remain unchanged and become inconsistent with the reverted guest.

Reverting does not necessarily remove the selected snapshot or the rest of the snapshot tree. Review Snapshot Manager after the operation. Retain snapshots only when there is a documented reason, and remove them according to operational policy.

Application and data consistency

A normal snapshot may not represent a fully coordinated application state. For workloads that write frequently, such as databases, consider application-aware procedures and quiesced snapshots where supported and appropriate. A quiesced snapshot attempts to capture a more application-consistent disk state by coordinating or briefly pausing guest activity, but it does not replace application-specific backup and recovery procedures.

Before reverting a database or transactional application, follow the application's recovery guidance. Confirm whether transactions, replication, queues, or external records need separate handling.

Post-Revert Validation

After the task completes, validate the VM rather than assuming that a successful vSphere task means the application is healthy.

  1. Check power state: Confirm that the VM is powered on or off as expected and that the guest operating system reaches a stable state.
  2. Check guest access: Sign in through the expected console, remote-access method, or management channel.
  3. Check services: Verify that required operating-system services, agents, and scheduled components are running.
  4. Check applications: Test the affected application and confirm that its expected version and configuration are present.
  5. Check networking: Validate the VM's address, DNS resolution, routes, firewall behavior, and connectivity to required dependencies.
  6. Check data: Confirm that important files and application records match the intended recovery point.
  7. Review tasks and events: Look for warnings, errors, failed guest services, or storage operations associated with the revert.
  8. Review snapshots: Decide whether the snapshot tree should be retained, cleaned up, or documented according to policy.
  9. Document the event: Record the VM, selected snapshot, reason, time, operator, observed data loss, validation results, and follow-up actions for production or shared systems.

Pre-Revert Checklist

CheckWhy it mattersHow to verify
Correct virtual machineReverting the wrong VM can interrupt another workload and cause unintended data loss.Verify the VM name, inventory location, host or cluster, and workload owner.
Correct snapshot date and descriptionA similarly named or older snapshot may represent the wrong recovery point.Review the name, timestamp, description, and snapshot-tree position.
Expected data loss understoodPost-snapshot changes may disappear from the VM's active state.List files, updates, installations, transactions, and configuration changes made afterward.
Application and stakeholder impact assessedReverting can interrupt sessions, services, users, and integrations.Notify owners, schedule a change window, and follow application recovery procedures.
Backup availability confirmedA snapshot may not provide independent or long-term recovery.Verify that a usable backup exists and identify its recovery procedure.
Snapshot operation completed successfullyA task error or incomplete operation can leave the VM unavailable or require further action.Review Recent Tasks, events, power state, guest health, and application tests.

Operational Cautions and Lifecycle Practices

  • Use snapshots as short-term recovery points, not as your backup strategy.
  • Avoid keeping snapshots for long periods. Snapshot chains can consume storage and may affect performance or require later consolidation.
  • Use meaningful names and descriptions that identify the purpose, owner, and change window, for example Before-OS-update-2026-08-18.
  • Maintain a snapshot lifecycle policy that defines who may create snapshots, how long they may remain, and when they must be removed.
  • For application-sensitive workloads, use application-aware or quiesced snapshots where supported and suitable, while still following the application's backup guidance.
  • Check datastore capacity before creating or retaining snapshots. Low free space can create operational risk.
  • Do not assume that reverting the VM reverses changes made to external systems, shared storage, directory services, cloud resources, or network devices.

Practical Revert Examples

Undoing a failed software installation

A test VM receives a new application and then fails during startup. The administrator opens Snapshot Manager, selects the snapshot taken before the installation, verifies the timestamp and description, and chooses Revert to. After completion, the administrator checks the guest boot process, services, and application state.

Rolling back an unsuccessful configuration change

A network or operating-system change prevents a development VM from functioning correctly. The administrator identifies the pre-change snapshot, confirms that newer work can be discarded, and reverts. Network settings, guest access, and dependent services are then tested.

Resetting a lab VM

Students modify a training VM during an exercise. At the end of the session, the instructor reverts it to a baseline snapshot so the next class receives a known starting state. The instructor confirms that the baseline snapshot is still appropriate and that the snapshot tree is not accumulating unnecessary points.

Validating before a production rollback

Before reverting a production workload, an administrator confirms the snapshot timestamp, identifies data created afterward, notifies affected users, and verifies that a current backup exists. After the revert, the administrator validates services, application behavior, connectivity, and data consistency, then documents the event.

Troubleshooting Revert Problems

The Revert action is unavailable

  • Possible cause: No snapshot exists for the selected VM. Check: Open Snapshot Manager and confirm that a snapshot is present.
  • Possible cause: The wrong inventory object is selected. Check: Confirm that the selected object is the target VM.
  • Possible cause: The account lacks snapshot-management permissions. Check: Ask a vSphere administrator to review the assigned role and permissions.
  • Possible cause: A conflicting VM task is in progress. Check: Review Recent Tasks and wait for the active operation to finish or be resolved.

The wrong snapshot was selected

If you notice the mistake before accepting the confirmation, cancel the operation and select the correct snapshot. If the revert has already completed, assess the restored state and use a backup or another approved recovery procedure if newer data is required. Vague names, missing descriptions, and failure to inspect the hierarchy are common causes.

Expected data is missing after the revert

The data may have been created or modified after the selected snapshot, or the application may store it outside the VM. The selected restore point may also be older than intended. Treat the missing data as expected post-snapshot change loss until proven otherwise, then evaluate backups, application recovery options, and external data sources.

The VM behaves unexpectedly after reverting

Guest services may not have started, the snapshot may predate a required dependency or network change, or application-consistency requirements may not have been met. Review VM events and tasks, inspect guest and application logs, validate network settings, and use an appropriate backup if the snapshot rollback is insufficient.

Exam-Relevant Notes

  • Revert returns a VM to a selected snapshot; it is not the same as deleting a snapshot.
  • Changes made after the selected snapshot can be lost from the VM's active state.
  • A snapshot can remain in the snapshot tree after a revert, so review and manage the tree afterward.
  • Snapshots are short-term rollback mechanisms and are not replacements for independent backups.
  • The selected snapshot's name, timestamp, description, and parent-child position should all be checked before confirmation.
  • After reverting, verify power state, guest operating system, services, applications, networking, and data.

Summary

To revert a VM, locate the correct VM in the vSphere inventory, open snapshot management, inspect the snapshot tree, select the intended snapshot, choose Revert to, and confirm only after reviewing the data-loss warning. Monitor the task until it completes, then validate the VM and its applications.

Good rollback practice combines careful snapshot selection, stakeholder communication, application-consistency planning, current backups, and snapshot lifecycle management. For related administration work, see VM snapshot revert guidance.