A checkpoint is not a backup: how Hyper-V checkpoints work

Before an application update, an administrator creates a checkpoint of the virtual machine, just in case. The update succeeds and the checkpoint stays. Four months later the volume holding the machines runs out of space, several machines go into a paused state, and the disk folder contains an .avhdx file of several hundred gigabytes that has received every write since the day of the update. Somebody suggests deleting it, because “it is only a checkpoint”.

A Hyper-V checkpoint is a tool for rolling back a change quickly, not a backup. It sits on the same storage as the machine, depends on its parent disk, and costs space and performance with every hour. This post shows how it works, when it makes sense, and how to find the checkpoints that have stayed too long.

How a checkpoint works: the AVHDX chain

When a checkpoint is created, the machine’s VHDX disk stops being written to. Hyper-V creates a differencing disk with the .avhdx extension next to it, and from then on all writes go there. The next checkpoint creates another AVHDX file whose parent is the previous one. The machine runs at the end of the chain, and reading a block that has not changed reaches through the levels all the way to the base VHDX.

D:\Hyper-V\Virtual Hard Disks\
  srv-app-01.vhdx                                          120 GB   chain base, read-only
  srv-app-01_6F1C2A4E-1B7D-4C3A-9E55-0A1B2C3D4E5F.avhdx     38 GB   changes between checkpoints 1 and 2
  srv-app-01_9A8B7C6D-5E4F-4A3B-8C2D-1E0F9A8B7C6D.avhdx     11 GB   active disk, current writes

This design has three consequences:

• Space. Every AVHDX file grows with each block written and can grow to the size of the whole disk. When the volume runs out of space, Hyper-V pauses the machines whose disks live on it (the Paused-Critical state), not only the one with the checkpoint.
• Performance. Every additional level of the chain means extra work on reads, and the machine’s data is spread across several files. Write-heavy machines, such as databases and file servers, feel it first.
• Dependency. An AVHDX file without its parent is useless. Damage to the base VHDX, or to the volume it sits on, destroys the machine and all its checkpoints at once.

Standard and production checkpoints

Hyper-V has two kinds of checkpoint, which differ in what they capture and the state in which they leave applications.

Type	What it captures	Application consistency	After applying
Standard	disks plus the machine’s memory and device state	none, the application is unaware of the checkpoint	the machine carries on from the moment of creation, with the same open connections and transactions
Production	disks after writes are frozen by VSS in a Windows guest or by a file system freeze in a Linux guest	as with a backup	the machine starts from power-off, as after a restore from backup

A standard checkpoint brings the machine back “mid-flight”, which for a database or a domain controller means returning to a state the rest of the environment knows nothing about. A production checkpoint requires the guest integration services responsible for backup (VSS) to be running. The type is set per machine:

# Production: production, falling back to standard if that fails
# ProductionOnly: production or an error, no silent fallback to standard
# Standard: always standard; Disabled: checkpoints turned off
Set-VM -Name srv-app-01 -CheckpointType ProductionOnly

The default value Production silently creates a standard checkpoint if the production one fails. For database servers and domain controllers ProductionOnly is better: a failed checkpoint shows up as an error, not as a checkpoint of a different type than intended.

Deleting means merging

Deleting a checkpoint in Hyper-V Manager or with Remove-VMSnapshot does not remove the file straight away. Hyper-V merges the contents of the AVHDX into the parent disk and only then deletes the file. In current Hyper-V versions merging happens while the machine runs, and its progress is visible in Hyper-V Manager. Merging a file of several hundred gigabytes takes time and puts a heavy load on storage, so a checkpoint kept for months is deleted in a maintenance window, not during working hours.

# Merges the changes into the parent disk, the machine keeps running
Remove-VMSnapshot -VMName srv-app-01 -Name 'before-update-JS-delete-by-2026-08-13'

Checkpoints on domain controllers

A domain controller running Windows Server 2012 or later, on a hypervisor that supports the VM-GenerationID identifier, detects that a checkpoint has been applied. After the restore the machine generation identifier changes, so the controller resets its invocation identifier (invocationID), discards its current RID pool and pulls changes from its replication partners. This protects against USN rollback, the situation in which the other controllers ignore changes from the restored one because they believe they have already seen them.

It is still not a backup. The checkpoint sits on the same storage as the controller. A restored controller receives all later changes from its partners anyway, deletions included, so a checkpoint will not bring back an object deleted by mistake. With the only controller in a domain, applying a checkpoint means losing every change made since it was created. The directory backup is a system state backup, described in Active Directory backup and forest recovery.

Recovery checkpoints left by backup jobs

Virtual machine backup software on Windows Server 2016 and later creates a Recovery-type checkpoint during the job and merges it afterwards. If the job is interrupted, the checkpoint may remain. The next job creates another one, and after a few weeks the machine has a chain of a dozen AVHDX files that nobody created on purpose. Checkpoints of this type are not always visible in Hyper-V Manager, so you look for them with PowerShell.

A leftover is removed only after making sure no backup job for the machine is in progress and after fixing the cause in the backup system. Otherwise the chain grows back within days:

# Run only when no backup job for this machine is in progress
Get-VMSnapshot -VMName srv-app-01 -SnapshotType Recovery | Remove-VMSnapshot

When a checkpoint makes sense

A checkpoint is a good tool in one scenario: before a specific change whose effects can be judged within hours. An operating system update, a new application version, a configuration change that might stop the machine from booting. Once the change is verified, the checkpoint is deleted.

Question	Checkpoint	Backup
Where it lives	on the same volume as the machine	on a different system and medium, off-site or offline
Survives a storage or host failure	no	yes
Survives ransomware with rights on the host	no	only an immutable or offline copy
Typical lifetime	hours, a few days at most	weeks and months according to retention
Cost of keeping it	grows with every write and every hour	constant, on separate storage
What it is for	quick rollback of a specific change	recovery after a failure, data loss or attack

A checkpoint’s name should say who created it, why, and when it is to be deleted. A default name such as “srv-app-01 - (11/08/2026 - 09:14:02)” tells nobody anything a month later:

Checkpoint-VM -Name srv-app-01 -SnapshotName 'before-update-JS-delete-by-2026-08-13'

Check your own environment

All checkpoints on the host with their age in days. In a failover cluster use Get-VM -ComputerName (Get-ClusterNode).Name instead of plain Get-VM:

Get-VM | Get-VMSnapshot |
    Select-Object VMName, Name, SnapshotType, CreationTime,
        @{ Name = 'AgeDays'; Expression = { [int]((Get-Date) - $_.CreationTime).TotalDays } } |
    Sort-Object CreationTime |
    Format-Table -AutoSize

A good result: an empty list, or checkpoints a few days old with names that point to a change. A bad result: ages measured in weeks, default names with a date, or Recovery entries.

Machines whose disks run on differencing files:

Get-VM | Get-VMHardDiskDrive |
    Where-Object Path -like '*.avhdx' |
    Select-Object VMName, ControllerType, Path

Every row is a machine with an active checkpoint. A machine running on an AVHDX file with no checkpoint in the Get-VMSnapshot output usually indicates a failed merge and calls for careful analysis, not for deleting files.

The disk chain of one machine with file sizes:

$path = (Get-VMHardDiskDrive -VMName srv-app-01 | Select-Object -First 1).Path
while ($path) {
    $vhd = Get-VHD -Path $path
    [pscustomobject]@{
        File   = Split-Path $vhd.Path -Leaf
        Type   = $vhd.VhdType
        SizeGB = [math]::Round($vhd.FileSize / 1GB, 1)
    }
    $path = $vhd.ParentPath
}

A good result is a single row of type Fixed or Dynamic. Every Differencing row is one level of the chain, and the sum of the sizes shows how much space the checkpoints take.

Leftovers from backup jobs and the configured checkpoint type:

Get-VM | Get-VMSnapshot -SnapshotType Recovery | Select-Object VMName, Name, CreationTime
Get-VM | Select-Object Name, CheckpointType

A Recovery checkpoint older than the machine’s last successful backup job is a leftover to investigate. A value of Standard on a database server or a domain controller is a setting to change.