How to Apply a Hyper-V Checkpoint in Windows 10

Applying a Hyper-V checkpoint returns a VM to an earlier state. Before doing it, identify the exact host, VM and checkpoint, protect changes made since that point, and decide how you will verify the restored workload. A checkpoint is not an independent backup.

1. Preserve what you might need afterward

1. Record the host and VM name, checkpoint name, creation time and reason it was created. A familiar name alone is not enough to choose the correct point.
2. Save guest work and separately back up files or application data changed since the checkpoint. Confirm that the backup can be used without relying on this checkpoint chain.
3. Allow for interruption and check host storage capacity before creating another checkpoint. If a backup or checkpoint operation is already running, let it complete or involve its administrator.
4. Plan for external state: reverting this VM does not roll back a remote database, cloud service or another computer it talks to.

2. Choose how to apply the checkpoint

Retaining the current state in another checkpoint gives you another recovery point, but does not create an independent backup or undo effects already sent to external systems.

3. Apply through Hyper-V Manager

1. Open Hyper-V Manager and select the intended host and VM.
2. In Checkpoints, compare the target's name and time with your notes.
3. Right-click that checkpoint and choose Apply.
4. Select the option from the table that matches your recovery plan. Wait for the operation to finish before starting another task.

Production checkpoints do not capture running memory as standard checkpoints do. After applying a production checkpoint, expect to start the VM and reopen applications rather than resume an unsaved desktop session. Do not infer how an older checkpoint was created solely from the VM's current checkpoint preference.

4. Optional PowerShell: inspect, preview, then confirm

Run these examples on the intended Hyper-V host in a PowerShell session with the required management rights. They target the local host. Replace LabVM with your VM's actual name. First list checkpoints without changing them:

Get-VMCheckpoint -VMName 'LabVM' |
    Format-List VMName, Name, Id, CreationTime

Copy the chosen checkpoint's full ID from that listing. Replace PASTE-CHECKPOINT-ID below and check the displayed VM, name and date. The selection must resolve to exactly one object:

$target = @(
    Get-VMCheckpoint -VMName 'LabVM' -ErrorAction Stop |
        Where-Object { $_.Id.ToString() -eq 'PASTE-CHECKPOINT-ID' }
)
if ($target.Count -ne 1) {
    throw 'Stop: exactly one checkpoint must match.'
}
$target | Format-List VMName, Name, Id, CreationTime
$target | Restore-VMCheckpoint -WhatIf

-WhatIf describes the planned operation; it does not restore the VM, create a safety checkpoint or prove that a later restore will succeed. If selection or preview fails, stop. Prepare any backup or current-state checkpoint separately before proceeding.

Only after reviewing that output and completing preparation, run this in the same unchanged session. Read the confirmation prompt and decline if the target is wrong:

if (@($target).Count -ne 1) {
    throw 'Stop: select and preview one checkpoint first.'
}
$target | Restore-VMCheckpoint -Confirm

The checkpoint cmdlets are aliases of the corresponding snapshot cmdlets in Microsoft's module documentation. This example deliberately retains confirmation and does not automatically choose the newest checkpoint or restore every VM.

5. Verify the workload, not just the VM status

Test one representative application task and verify the data you intended to recover. Keep your separate backup until the outcome is confirmed. A running VM alone is not evidence that every service or transaction is correct.

Recovering from the wrong choice

If you preserved the pre-restore state, assess whether returning to it is appropriate using the same identification and preparation checks. If you chose Apply without preserving that state, do not assume an Undo action will reconstruct newer data; recovery depends on another usable checkpoint or backup.

Once the restored workload is verified, plan checkpoint cleanup separately. Use Hyper-V's checkpoint management so it can handle the disk chain. Never delete .avhdx files directly to free space or force a restore to complete.

Documentation review: 7 October 2026. This is a documentation-based workflow, not a claim of a hands-on repair. No service-account permissions, Windows features or virtual-machine checkpoints were changed for this review.

Official references