Skip to main content

Orphaned Checkpoint (AVHDX) Chain on a Hyper-V Guest After Veeam

Field Detail
Audience T3 / Code Commanders only
Version 1.0
Last Updated October 2026
Applies To Hyper-V guests backed up by Veeam B&R 13.1.1.18
Source HALO 1179664

⚠️ Read this whole page before touching anything. Pointing a disk at the wrong parent corrupts the VM. Nothing on this page deletes a file, and nothing should until a good backup of the recovered VM exists.

Signal

  • The VM's folder holds many .avhdx layers — more than one checkpoint chain should ever need.
  • Veeam shows the VM's provisioned size far larger than its real disks, or the backup fails on it.
  • Hyper-V reports a merge pending, or its background merge fails with "file in use".
  • After a restart, the guest is missing recent changes — the VM config is pointing at an older layer than the newest one on disk.

Cause

Veeam takes a Hyper-V checkpoint for each backup and merges it away afterwards. When that merge fails — observed when a backup started while Hyper-V was still merging, so the files were in use — the layer stays behind and the next backup stacks another on top. Over time the chain branches, and the VM config can end up pointing at an older branch than the one the guest was last writing to.

On one domain controller, 18 layers had built up this way, and the live branch held four days of changes the config no longer pointed at. Why the merges fail is not fully diagnosed — check that before the final merge.

Procedure

1. Protect what's there

  1. Shut the VM down cleanly.
  2. Pause the VM's backup job so nothing touches the files mid-repair. Note it: it must be re-enabled at step 6 — see Veeam Jobs All Disabled.
  3. Copy every .vhdx and .avhdx for the VM to a safe folder on another volume with room. Leave the originals in place.

2. Map the chain

On the Hyper-V host:

$vm = '<VM>'
Get-VMHardDiskDrive -VMName $vm | Select-Object ControllerType, ControllerNumber, ControllerLocation, Path
Get-ChildItem '<VM disk folder>' -Filter *.avhdx | Sort-Object LastWriteTime | Select-Object Name, LastWriteTime, @{n='GB';e={[math]::Round($_.Length/1GB,1)}}

Walk any layer back to its base:

$p = '<layer .avhdx>'; while ($p) { $v = Get-VHD -Path $p; '{0}  <- parent {1}' -f $v.Path, $v.ParentPath; $p = $v.ParentPath }

Find two things: the leaf the config points at, and the newest leaf on disk — the one with the latest LastWriteTime. If they differ, the newest one holds the guest's real latest state.

3. Reattach a branch to its parent, if needed

If the newest leaf's chain breaks because its parent was merged or replaced, reattach it to the correct parent:

Set-VHD -Path '<child .avhdx>' -ParentPath '<correct parent>' -IgnoreIdMismatch

-IgnoreIdMismatch overrides Hyper-V's safety check. Use it only when you have confirmed the parent is the disk this branch was taken from. If you are not certain, stop here and escalate.

4. Point the VM at the live leaf

Hyper-V refuses to edit a disk with a merge pending. Removing and re-adding the drive clears that:

Remove-VMHardDiskDrive -VMName $vm -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0
Add-VMHardDiskDrive -VMName $vm -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path '<live leaf .avhdx>'

Use the controller values from step 2. Generation 1 VMs boot from IDE, not SCSI.

5. Boot and check the guest

Start the VM and confirm the most recent work is present. For a domain controller, check that recent account and DNS changes exist and that replication is healthy.

6. Back it up before anything else

Re-enable the job and let a backup complete successfully. Until it has, keep the safe copies from step 1.

7. Merge the chain, later

Only after a good backup, and with no backup running, merge the layers down: shut the VM down and pause its backup job, merge, then re-enable the job. Investigate why Veeam's merges failed first, or the layers will build up again.

Version Date Author Change
1.0 October 2026 Z. Boogher Initial release from a domain-controller chain recovery during the v13 upgrade (HALO 1179664).
Back to top