VM Snapshot Rollback: What It Restores and What It Does Not
A VM snapshot restores guest disk and memory state, not remote account actions, shared-file copies or records held elsewhere: scope the rollback first.
A checkpoint puts part of the guest back and leaves every other system where it was. What left the guest — a delivered message, a file copied to the host, an account action a website accepted — belongs to the system that received it, not to the checkpoint. The rollback has a defined local scope, and calling it erasure turns a recovery plan into a false statement. The table below is the checklist for what a restore actually reaches.
The desktop comes back, the remote session does not
The usual complaint arrives after the fact. The virtual machine boots into last week's state, the browser history is gone, and the service the user signed into still lists the session as active. Nothing is broken; the two systems were never in the same transaction.
| Where the effect landed | Who owns undoing it | How you verify it is gone |
|---|---|---|
| Guest virtual disk | The hypervisor, through the checkpoint you restore | The disk state matches the checkpoint's timestamp |
| Guest memory | Only a checkpoint type that saved memory | The guest resumes or cold-boots, as that type dictates |
| Host share or clipboard | The owner of that host path | The copied file is absent at its destination |
| Remote account or session | The service that accepted the action | The session list shows nothing active for that account |
| Mail or message queue | The mail system that delivered it | The message is gone from the recipient's mailbox, not from the guest |
That mismatch is the lesson. A checkpoint restores what the hypervisor tracks: the guest's virtual hardware and, depending on the type, its memory. It does not track a web application's session table, a mail server's delivery queue or a colleague's downloads folder. Read the type before restoring, because the type decides what a restore can recover at all.
What the hypervisor actually saved
Microsoft's Hyper-V documentation distinguishes standard checkpoints, which capture memory along with the virtual disks, from production checkpoints, which use a data-consistent mechanism and skip memory. A standard checkpoint resumes at the instruction the guest was executing; a production one boots from a consistent disk instead. That difference decides whether a restore returns a running process or a clean start. Do not carry the behaviour of one hypervisor into another, because the terms and the consistency mechanism change between products.
Microsoft also warns that a checkpoint is not a backup, and the warning matters. A chain of checkpoints on one volume shares that volume's fate, so it protects against a bad change rather than a lost host.
Files that live outside the guest disk
A shared folder is a host filesystem presented to the guest, and reverting the guest does not revert it. If the user downloaded a file inside the guest and copied it out through a shared path, that second copy has its own lifecycle and its own owner. Restoring the guest removes the first copy and leaves the second exactly where it was put.
Ask who owns each path before promising a rollback. A host share, a clipboard transfer and an upload to a cloud drive are three destinations, and only the first might sit next to the hypervisor's storage.
Where a copy must genuinely be removed, remove it at its destination and record that step separately. A recovery plan that lists only the snapshot is incomplete in a way nobody notices until the copy is found. The same caution applies to logs the host wrote while the guest was running.
Accounts the hypervisor never saw
Anything a service accepted from the guest is the service's record, not the guest's. The hypervisor never saw that transaction, so it cannot reverse it. A password change, a purchase, a posted message and an API call all persist in the system that processed them. Restoring a disk image does not reach that system.
Browser state makes the mismatch concrete. A restored guest may hold an earlier cookie for a service that has since rotated the session, so the user looks signed in and is silently rejected, or looks signed out while the service still considers the session valid. Revoking the session at the service is the only operation that ends it.
What a restore cannot undo
A checkpoint is useful for an approved test or a configuration experiment whose scope is understood. It is a local undo for local state, which is a narrower promise than it sounds, and it is not evidence that the host, the hypervisor or any external system stayed clean. A VPN changes which path the packets take; it does not turn the software in the guest into something safe to run. The two claims are separate and only one of them is about the tunnel.
$cp = Get-VMSnapshot -VMName lab-desktop -Name baseline
Get-VMHardDiskDrive -VMSnapshot $cp | Select-Object ControllerType, ControllerNumber, ControllerLocation, PathThe first line resolves the checkpoint to an object, and the second lists the disks it covers, which answers the scope question with evidence instead of memory. Rotate and revoke an exposed secret at the service that owns it. Where known malicious code is in play, use an authorised investigation environment and the organisation's response process rather than assuming a snapshot makes execution safe.
Write down three things before the restore: which guest state you are taking back, which outside systems still hold the effect, and the point you will trust afterwards. That plan is a stronger claim than a machine that once again looks familiar. Keep it with the ticket so the next restore starts from the same list.