How to Create a Hyper-V Checkpoint in Windows 10

Create a Hyper-V checkpoint before a planned VM change, then confirm it completed before proceeding. First decide whether you need a production checkpoint or a standard checkpoint: the configured fallback can otherwise produce a different kind of recovery point than you intended.

1. Choose the checkpoint behavior deliberately

In Hyper-V Manager > VM Settings > Management > Checkpoints, inspect both the selected type and the fallback checkbox. For production-only behavior, select production checkpoints and clear the option to create a standard checkpoint when production creation is unavailable. Record the old setting before changing it.

2. Check backup, capacity and workload requirements

A checkpoint retained beside the VM is not an independent backup. Keep a separate, verified backup appropriate to the workload before a consequential change. Rolling a guest back also does not roll back messages, payments or other actions already sent to external systems.

Check free space on the actual virtual-disk storage, not only the checkpoint configuration-file location. Differencing disks grow as data changes, and cleanup needs room to complete. There is no single free-space percentage suitable for every VM: consider workload write volume, the test duration and the existing checkpoint chain.

Decide who owns the checkpoint and when it should be removed. Coordinate with backup software and other administrators; avoid starting overlapping checkpoint or backup operations. For replicated services, databases or directory servers, follow the application's supported backup and recovery procedure rather than assuming any VM checkpoint is sufficient.

3. Create and name the checkpoint

Confirm the host and exact VM in Hyper-V Manager, right-click the VM and choose Checkpoint. Wait for the operation to finish. Give the completed checkpoint a descriptive name such as “Before application update,” with enough context to distinguish it from an automatic checkpoint.

Alternatively, use PowerShell on the correct Hyper-V host with the required administrative rights. Replace the example VM name; these commands first inspect its configured policy, then create a checkpoint using that policy:

Get-VM -Name "LabVM" | Select-Object Name, State, CheckpointType
Checkpoint-VM -Name "LabVM" -SnapshotName "Before application update"

The creation command does not itself request production-only behavior. If required, configure that policy first through the settings above. Do not proceed with the planned update merely because the command was issued.

4. Confirm completion without applying it

Look for the new entry beneath the correct VM and confirm its name and timestamp. A read-only inventory is also available:

Get-VMSnapshot -VMName "LabVM" | Select-Object Name, CreationTime

If the entry is missing, the operation is still running or an error occurred, stop and investigate. When production-only is required, confirm that policy was set before creation and that creation succeeded; a reassuring name such as “Production backup” proves neither.

Listing a checkpoint verifies its presence, not successful application recovery. Test restoration separately on an isolated, noncritical copy when a recovery assurance is needed. Do not click Apply on a working VM just to check whether the new entry exists.

5. Handle a failure without weakening the requirement

Save the full error, host and guest versions, VM name, checkpoint policy, available storage and any concurrent backup activity. Microsoft's checkpoint troubleshooting identifies insufficient space, guest/backup integration problems and file locks among the possible causes; the exact error determines the next investigation.

If production creation fails, do not silently switch to Standard to obtain a successful-looking entry. Resolve the guest consistency problem or agree on a different backup plan. If storage is nearly full, pause the planned change and arrange capacity or supported cleanup; do not delete virtual-disk files in Explorer.

6. Finish the test and clean up through Hyper-V

Once the planned change and application checks succeed, take the required backup and retire the temporary checkpoint through Hyper-V Manager. Deleting a checkpoint removes that rollback point and merges its disk changes; it does not mean reverting the VM to that point.

Confirm the exact checkpoint before deletion, allow the merge to finish, and check the VM and storage afterward. Do not manually delete .avhdx files, detach a disk chain to reclaim space or interrupt a merge because the entry has disappeared from the list. A failed cleanup needs investigation of the existing chain and backup activity.

If rollback is actually needed, first protect newer work and review the consequences in the separate checkpoint restoration guide. Applying and deleting are different actions.

Documentation review: 14 October 2026. Checked against Microsoft Hyper-V and PowerShell documentation. The screenshot is vendor documentation; no checkpoint was created or applied on a user's VM for this review.

Official references

Microsoft — Create and manage checkpointsManager settings, checkpoint lifecycle and the credited screenshot. Microsoft — Set-VM checkpoint policyProduction fallback versus ProductionOnly failure behavior. Microsoft — Checkpoint-VMTargeting and naming a checkpoint through PowerShell. Microsoft — Get-VMSnapshotRead-only checkpoint inventory. Microsoft — Checkpoint and differencing-disk failuresServer-oriented diagnostic reference for storage, locks and checkpoint-chain problems; advanced repair needs host-specific assessment.