How to Configure Hyper-V Checkpoints (Snapshots) on Windows Server 2025

Hyper-V checkpoints — formerly known as snapshots — capture the complete state of a virtual machine at a specific point in time, including memory contents, processor state, and disk configuration. On Windows Server 2025, Hyper-V offers two distinct checkpoint types with fundamentally different consistency guarantees: Standard checkpoints capture memory and disk state exactly as-is regardless of what the guest OS is doing, while Production checkpoints coordinate with the guest through the Volume Shadow Copy Service (VSS) to flush application write caches before the snapshot is taken, producing a backup-quality, application-consistent image. Choosing the wrong type for a production SQL Server or Active Directory domain controller can result in USN rollback, database corruption, or split-brain conditions. This tutorial explains both types in depth, covers the full PowerShell management workflow, explores checkpoint chains and disk space impact, and provides best-practice guidance for production environments.

Prerequisites

Windows Server 2025 with the Hyper-V role installed
At least one existing virtual machine managed by this Hyper-V host
PowerShell 5.1 or later running as Administrator on the Hyper-V host
Hyper-V Manager or Remote Server Administration Tools (RSAT) installed
Adequate free disk space on the storage volume that holds VM files (checkpoints can grow to the size of the parent VHD)
Hyper-V Integration Services installed and current inside each guest VM

Step 1: Understand Checkpoint Types

Before creating any checkpoint, understand the fundamental difference between the two types so you can make the right choice for each workload.

Standard Checkpoints (Crash-Consistent)

Standard checkpoints capture a live snapshot of memory and disk at the instant the command executes. The VM does not pause; data that was in memory buffers or in-flight to disk at that exact moment may not be fully committed. Restoring a Standard checkpoint is equivalent to power-cycling the VM from that point in time — applications will run crash recovery on restart. Standard checkpoints are acceptable for development and test VMs where transient application state does not matter.

Production Checkpoints (VSS Application-Consistent)

Production checkpoints trigger a VSS quiesce operation inside the guest before the disk snapshot is taken. VSS instructs all VSS-aware writers — SQL Server, Exchange, Active Directory — to flush their memory buffers and bring their data files to a consistent state on disk. Only the disk is snapshotted; memory state is NOT preserved. On restore, the VM boots cold from a consistent disk image, exactly as a proper backup restoration would work. This is the only safe type for production database and directory service VMs.

# List current checkpoint type for a VM
Get-VM -Name "MyProductionVM" | Select-Object Name, CheckpointType

# View all available checkpoint type options
# Valid values: Disabled | Standard | Production | ProductionOnly
[enum]::GetValues([Microsoft.HyperV.PowerShell.CheckpointType])

Step 2: Configure the Checkpoint Type

Set the checkpoint type on each VM based on its role. Use Set-VM to change the type. For VMs where checkpoints should never be allowed — such as VMs that are replicated to another site via Hyper-V Replica — set the type to Disabled.

# Configure a production VM to use Production checkpoints only
Set-VM -Name "MyProductionVM" -CheckpointType Production

# Configure a test VM to use the default Standard type
Set-VM -Name "MyTestVM" -CheckpointType Standard

# Disable checkpoints entirely for a replicated or sensitive VM
Set-VM -Name "MyReplicaSourceVM" -CheckpointType Disabled

# Apply Production checkpoints to all VMs on this host at once
Get-VM | Where-Object { $_.State -eq "Running" } |
    Set-VM -CheckpointType Production

# Verify the setting was applied
Get-VM | Select-Object Name, CheckpointType | Format-Table -AutoSize

Step 3: Create a Checkpoint

Use Checkpoint-VM to create a checkpoint. Always supply a descriptive SnapshotName that includes the date and the reason for the snapshot so you can identify it later without opening Hyper-V Manager.

# Create a named Production checkpoint before applying updates
$VMName   = "MyProductionVM"
$SnapName = "Pre-Update-$(Get-Date -Format 'yyyyMMdd-HHmm')"

Checkpoint-VM -Name $VMName -SnapshotName $SnapName

Write-Host "Checkpoint '$SnapName' created for VM '$VMName'"

# Create checkpoints for all running VMs simultaneously
Get-VM | Where-Object { $_.State -eq "Running" } | ForEach-Object {
    $snap = "Batch-$(Get-Date -Format 'yyyyMMdd')"
    Checkpoint-VM -VM $_ -SnapshotName $snap
    Write-Host "Checkpoint created for: $($_.Name)"
}

# Verify the checkpoint was created
Get-VMSnapshot -VMName $VMName

Step 4: List and Inspect Checkpoints

Hyper-V stores checkpoints in a tree structure. Each checkpoint has a parent, and multiple checkpoints can branch from the same parent, forming a tree. The Get-VMSnapshot cmdlet returns all checkpoints with their parentage, creation time, and snapshot type.

# List all checkpoints for a specific VM
Get-VMSnapshot -VMName "MyProductionVM" | Select-Object Name, SnapshotType, CreationTime, ParentSnapshotName

# List checkpoints across all VMs on the host
Get-VM | ForEach-Object {
    $vm = $_
    Get-VMSnapshot -VMName $vm.Name | Select-Object `
        @{N="VM";E={$vm.Name}}, Name, SnapshotType, CreationTime
} | Format-Table -AutoSize

# Count checkpoints per VM (alert on VMs with many checkpoints)
Get-VM | ForEach-Object {
    $count = (Get-VMSnapshot -VMName $_.Name).Count
    [PSCustomObject]@{
        VM              = $_.Name
        CheckpointCount = $count
        Warning         = if ($count -gt 5) { "HIGH" } else { "OK" }
    }
} | Format-Table -AutoSize

# Get the checkpoint currently applied to the VM (the Now pointer)
Get-VMSnapshot -VMName "MyProductionVM" | Where-Object { $_.IsCurrentSnapshot }

Step 5: Restore a Checkpoint

Restoring a checkpoint rolls the VM back to the captured state. For Production checkpoints, the VM boots cleanly from the quiesced disk image. For Standard checkpoints, the VM resumes with the exact memory and processor state that was captured — the VM continues running from that moment as if nothing happened between then and now.

# Get the specific checkpoint object to restore
$VMName   = "MyProductionVM"
$SnapName = "Pre-Update-20260517-0900"

$Checkpoint = Get-VMSnapshot -VMName $VMName -Name $SnapName

# IMPORTANT: Stop the VM before restoring a Production checkpoint
# (Production checkpoints restore to a cold-boot state anyway)
Stop-VM -Name $VMName -Force

# Restore the checkpoint
Restore-VMSnapshot -VMSnapshot $Checkpoint -Confirm:$false

# Start the VM after restore
Start-VM -Name $VMName

# Monitor the VM startup
Get-VM -Name $VMName | Select-Object Name, State, Status

# Alternatively, restore to the last checkpoint using pipeline
Get-VMSnapshot -VMName $VMName |
    Sort-Object CreationTime |
    Select-Object -Last 1 |
    Restore-VMSnapshot -Confirm:$false

Step 6: Delete Checkpoints and Understand the Merge Process

Deleting a checkpoint does not immediately reclaim disk space. Hyper-V must merge the AVHD/AVHDX differencing disk back into the parent VHD. This merge happens automatically in the background while the VM is running (for Production checkpoints) or requires the VM to be turned off (for Standard checkpoints when a merge conflicts with a running machine). The merge can take significant time for large disks and generates heavy I/O — plan deletions during a maintenance window.

# Delete a specific checkpoint by name
$VMName   = "MyProductionVM"
$SnapName = "Pre-Update-20260517-0900"

Remove-VMSnapshot -VMName $VMName -Name $SnapName

# Confirm the checkpoint was removed
Get-VMSnapshot -VMName $VMName

# Delete ALL checkpoints for a VM and merge all AVHD files
# WARNING: This cannot be undone. All checkpoint history is lost.
Get-VMSnapshot -VMName $VMName | Remove-VMSnapshot -Confirm:$false

# Monitor the background disk merge progress
# The AVHD file will shrink and disappear when the merge is complete
Get-VM -Name $VMName | Select-Object Name, Status

# Alternatively watch the AVHD files on disk
Get-ChildItem -Path (Get-VM -Name $VMName).ConfigurationLocation `
    -Recurse -Filter "*.avhd*" | Select-Object Name, Length

Step 7: Understand Checkpoint Chains and Disk Space Impact

Every checkpoint creates an AVHDX differencing disk that records all writes made after the checkpoint was taken. If you take checkpoints frequently without deleting old ones, you build a chain of differencing disks. Reads must traverse the entire chain from newest to oldest, increasing read latency with each additional link. A long chain also means that deleting an old checkpoint triggers a multi-stage merge that can consume as much I/O as copying the entire disk.

# Estimate total disk space consumed by checkpoint chains
$VMName = "MyProductionVM"
$VM     = Get-VM -Name $VMName

# Find the VM storage path
$StoragePath = $VM.ConfigurationLocation

# List all VHD/AVHD files and their sizes
Get-ChildItem -Path $StoragePath -Recurse -Include "*.vhd","*.vhdx","*.avhd","*.avhdx" |
    Select-Object Name, @{N="SizeMB"; E={[math]::Round($_.Length/1MB,1)}} |
    Format-Table -AutoSize

# Get VHD chain info for a specific disk
$VHDPath = (Get-VMHardDiskDrive -VMName $VMName).Path
Get-VHD -Path $VHDPath | Select-Object Path, VhdType, Size, FileSize, ParentPath

# Calculate chain depth
function Get-VHDChainDepth {
    param([string]$VHDPath)
    $depth = 0
    $vhd = Get-VHD -Path $VHDPath
    while ($vhd.ParentPath) {
        $depth++
        $vhd = Get-VHD -Path $vhd.ParentPath
    }
    return $depth
}

Get-VHDChainDepth -VHDPath $VHDPath
Write-Host "Chain depth: $(Get-VHDChainDepth -VHDPath $VHDPath) differencing disks"

Step 8: Best Practices for Production VMs

Checkpoints are a powerful operational tool but they are not a substitute for proper backups and should be managed with discipline in production environments.

Always use Production checkpoints for servers running SQL Server, Active Directory, Exchange, or any VSS-aware application. Standard checkpoints on an Active Directory domain controller can cause USN rollback — a serious and difficult-to-recover condition.
Delete checkpoints promptly after they are no longer needed. A checkpoint left in place for weeks or months will accumulate a large AVHD and degrade VM disk performance.
Never take checkpoints on VMs configured with Hyper-V Replica. Checkpoints and replication interact poorly; use the Disabled checkpoint type on replicated VMs.
Automate checkpoint creation and deletion with scheduled PowerShell jobs rather than relying on operators to remember.

# Example: automated pre-maintenance checkpoint script
param(
    [string]$VMName = "MyProductionVM",
    [int]$RetainHours = 24
)

# Create a timestamped checkpoint
$SnapName = "Auto-$(Get-Date -Format 'yyyyMMdd-HHmm')"
Checkpoint-VM -Name $VMName -SnapshotName $SnapName
Write-Host "Created checkpoint: $SnapName"

# Delete checkpoints older than the retention period
$Cutoff = (Get-Date).AddHours(-$RetainHours)
Get-VMSnapshot -VMName $VMName |
    Where-Object { $_.CreationTime -lt $Cutoff } |
    ForEach-Object {
        Write-Host "Deleting expired checkpoint: $($_.Name)"
        Remove-VMSnapshot -VMSnapshot $_ -Confirm:$false
    }

# Report remaining checkpoints
Get-VMSnapshot -VMName $VMName |
    Select-Object Name, CreationTime, SnapshotType |
    Format-Table -AutoSize

Conclusion

Hyper-V checkpoints on Windows Server 2025 are an essential operational tool when used correctly and a significant risk when misused. The distinction between Standard (crash-consistent) and Production (VSS application-consistent) checkpoints is not merely cosmetic — it determines whether restoring a snapshot leaves your virtual machines in a healthy, recoverable state or in a corrupted, split-brain condition. Always configure Production checkpoints on servers running databases, directory services, and messaging workloads. Keep checkpoint chains short by deleting stale checkpoints regularly, monitor AVHD disk usage to prevent storage exhaustion during background merges, and never rely on checkpoints as your sole data protection strategy. Pair checkpoint discipline with a proper backup solution — such as Azure Backup Server, Veeam, or Windows Server Backup — to ensure full recovery capability in the event of host hardware failure.

Links

Newsletter

Contact