Has anyone seen Veeam Backup & Replication 12.3.2 create Hyper-V checkpoints and then remove them from the VM configuration without merging the AVHDX differencing disks?
This is a three-node Windows Server 2022 Failover Cluster with Pure FlashArray storage backing the CSVs. One VM, a SQL Server 2019 host, accumulated 46 orphaned AVHDX files across two virtual disks over three days, using roughly 675 GB. `Get-VMSnapshot` showed nothing, and Hyper-V Manager displayed no checkpoints. The VM was running from the tip of a 23-level differencing chain.
The unusual part is that the VMMS event log contains no merge events for this VM—not failed or interrupted merges, but no merge attempts at all. Other VMs on the same host regularly logged clean 19070-to-19080 event pairs. This makes it appear that Veeam created the checkpoint and removed its registration without asking Hyper-V to merge it.
I shut down the VM and flattened both chains with `Convert-VHD` to another CSV, then repointed the disks. `Test-VHD` passed before and after, and SQL Server started normally with all 14 databases online and current through shutdown. However, the problem happened again: the next backup run against the newly flattened VHDX files created two more orphaned AVHDX files, again with no registered checkpoints or Hyper-V merge events. A cluster-wide review found that this is the only VM affected across all three nodes.
Has anyone encountered this behavior with Veeam and Hyper-V, or found a configuration or known issue that explains why the checkpoint registration disappears without a merge?
2 Answers
A failed backup or another problem during checkpoint cleanup can leave AVHDX files behind, although this case is unusual because there are no corresponding Hyper-V merge events. Third-party backup integrations with Hyper-V have caused orphaned checkpoints before, so Veeam support should review the job logs, VM configuration, and cluster/storage details. They may also require testing on a newer supported Veeam build before investigating further.
The manual remediation is reasonable as an emergency measure, but repeatedly converting or merging disks on a SQL Server VM carries risk and does not address the cause. Preserve the AVHDX files and logs before cleanup, verify the parent-child chain, and involve the vendor rather than deleting the files directly. A support engineer can determine whether Veeam is deregistering the checkpoint prematurely or whether Hyper-V/cluster storage is losing the checkpoint state.
That is why I would not treat this as a routine abandoned-checkpoint cleanup. Other VMs are merging normally, and this VM reproduces the problem even after being rebuilt with flat disks.
That is the next step. The lack of any merge events is what makes this look different from a normal failed consolidation, so I am collecting the job and VMMS logs for support.