Before you touch a virtual machine’s configuration, apply an update, or install new software, it pays to save the state it was in. That’s what Hyper-V checkpoints are for: if the change breaks something, you roll back to the earlier point and move on. What many people miss is that not all checkpoints behave the same way.
Two types, two behaviors
Hyper-V on Windows 10 and 11 works with two kinds of checkpoint, and the difference comes down to what gets captured.
A standard checkpoint takes a snapshot of the virtual machine and its memory state at the moment the checkpoint is created. So it saves not only the disks but also what was in RAM: open processes, running applications, the lot. Microsoft’s documentation flags one thing worth remembering: a snapshot is not a full backup, and it can cause data consistency issues with systems that replicate data between nodes, such as Active Directory. Before Windows 10, this was the only type available (back then it was called a snapshot).
A production checkpoint works differently. It uses Volume Shadow Copy Service (VSS) on Windows VMs, or File System Freeze on Linux VMs, to create a data-consistent copy. It does not save the memory state. In exchange, you get something closer to what a conventional backup tool produces.
By default, Hyper-V selects production checkpoints. You can change that from Hyper-V Manager or with PowerShell, for example Set-VM -Name <vmname> -CheckpointType Standard. There’s also a ProductionOnly mode, which avoids falling back to a standard checkpoint if the production one fails.
How the difference shows when you apply them
The distinction is clearest when you revert. If you create a standard checkpoint with Notepad open and a file loaded, then apply it, the VM returns to exactly that state: Notepad is still open, with its content. The memory was restored as it was.
With a production checkpoint the result is different. When you apply it, the virtual machine ends up in an off state. When you start it again, the text file you saved to disk is there, but Notepad is not open. That’s exactly what you’d expect: only the data state was restored, not the memory.
What happens under the hood
Checkpoints are stored as .avhdx files in the same location as the VM’s .vhdx files. When you delete a checkpoint, Hyper-V merges the .avhdx into the .vhdx for you and then removes the .avhdx. You should not touch those files by hand. The default folder for checkpoint configuration is %systemroot%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots.
One naming detail: by default a checkpoint is named after the VM plus the date and time it was taken, and the name is limited to 100 characters.
Who this is useful for
If you run a lab or a test environment, standard checkpoints give you the full picture so you can replay a scenario again and again. If you manage workloads whose data must stay coherent (a domain controller, a database), production checkpoints are the sensible choice, which is why they’re selected by default.
This logic of snapshots and backups isn’t unique to Hyper-V. Other hypervisors handle it their own way, as we saw in the XCP-ng 8.3 LTS June 2026 update set, where data consistency also matters.