Recently I faced an interesting issue with a Hyper-V VM backup in Veeam. One specific VM suddenly started failing during checkpoint creation, while all the other VMs in the environment continued to be protected normally.
What made the case more interesting was that there was nothing obviously wrong with the affected VM. It was powered on, the operating system was accessible and the applications were working normally. From a production perspective, everything looked fine.
However, every backup attempt failed with the following error:
Failed to create VM recovery checkpoint (mode: Crash consistent)Checkpoint operation for 'SRV-IA-CONATA' failed.Checkpoint operation for 'SRV-IA-CONATA' was cancelled.'SRV-IA-CONATA' could not initiate a checkpoint operation:Incorrect function. (0x80070001).Error code: '32768'.Retrying snapshot creation attempt(Failed to create production checkpoint.)Unable to allocate processing resources.Error: Failed to create production checkpoint.
Finding the real problem
Since the error was related to checkpoint creation, the investigation moved to Hyper-V itself. One of the things I always find useful in situations like this is trying to reproduce outside Veeam what the backup is asking the hypervisor to do.
During the investigation, I discovered an important detail: the virtual disks of this VM had previously been moved to another storage location. However, the movement had been performed outside the native Hyper-V migration process.
One of the paths involved was:
F:\VMs\SRV-IA-CONATA_NEW\Virtual Hard Disks\SRV-IA-CONATA_4CD51627-5491-4592-82D9-8D22848494D2.avhdx
This explained why the situation was a little confusing at first. Even after the disk movement, the VM continued running normally. There was no immediate outage or obvious indication that something was wrong with its storage configuration.
The problem only became visible when Hyper-V needed to perform another operation involving the VM disk/checkpoint structure.
At this point, a colleague from my team who specializes in Hyper-V helped me with the Hyper-V side of the troubleshooting. Instead of manually changing the files again, the VHDX and the other VM dependencies were moved to a new location using the native Hyper-V Move functionality.
After the movement and synchronization were completed, the VM was started again and we tested a Production Checkpoint manually from Hyper-V Manager.
This time it worked.
That was an important validation because it confirmed that Hyper-V itself was able to create checkpoints again. Only after that did I go back to Veeam and test the backup.
The backup worked, but there was one more detail
The next backup was able to create the checkpoint and process the VM, so the original problem was resolved. However, the job finished with a warning that caught my attention:
Cannot use CBT: There is no change tracking data available associatedwith the specified change tracking identifier.Failed to query changes for disk'F:\VMs\SRV-IA-CONATA_NEW\Virtual Hard Disks\SRV-IA-CONATA_4CD51627-5491-4592-82D9-8D22848494D2.avhdx'.
The previous change tracking information could no longer be used. As a result, even though this was an incremental job, Veeam had to read the entire 120 GB virtual disk during this execution.
In this particular case, it wasn’t a big problem. The disk was relatively small, Veeam read the 120 GB at around 236 MB/s and the job completed in approximately 19 minutes.
But this is something worth paying attention to after this type of correction. Imagine the same situation with a VM containing several terabytes of data. The checkpoint problem may already be fixed, but losing the ability to use the previous CBT information can make the next backup considerably heavier than expected, increasing the amount of data that needs to be read and potentially extending the backup window.
Because of that, I didn’t consider the troubleshooting finished just because the first backup completed.
One more backup to confirm everything
I ran the job again and this time the behavior was back to normal. The VM was processed successfully and CBT was being used again:
Hard disk 1 (120 GB) 153 MB read at 12 MB/s [CBT]
Instead of reading the entire 120 GB virtual disk, only 153 MB had to be read during that execution. Subsequent backups also continued to run successfully.
That final execution was important because it confirmed not only that checkpoint creation had been fixed, but also that the normal incremental backup behavior had been restored.
A note about the AVHDX
Another detail that caught my attention during the investigation was the AVHDX file in the affected path.
AVHDX files are used by Hyper-V as differencing disks associated with checkpoints. Their presence alone doesn’t mean there is a problem, but they deserve attention when investigating checkpoint issues, especially if VM files have previously been moved or manipulated manually.
In this case, the important lesson wasn’t simply “there was an AVHDX file”. It was understanding that files involved in the VM disk/checkpoint structure had been moved outside the native Hyper-V process while the VM continued to appear healthy.
This is also why I wouldn’t recommend trying to solve a similar problem by simply deleting AVHDX files. They can contain active differencing data, and incorrect manipulation can turn a backup issue into a much more serious VM problem.
Final thoughts
What I liked about this case was that the initial symptom appeared in Veeam, but the root cause was actually outside Veeam.
The VM was running normally, but its disks had previously been moved outside the native Hyper-V process. When the backup required Hyper-V to create a checkpoint, the problem finally became visible.
After moving the VM storage and its dependencies correctly through Hyper-V, we were able to create a Production Checkpoint manually and the backup started working again. The first execution couldn’t use the previous CBT information and had to read the entire 120 GB disk, but the following backup confirmed that CBT was working normally again.
For a small VM, this additional read wasn’t a big deal. With a multi-terabyte VM, however, the same situation could mean a much longer backup window and considerably more I/O.
For me, the main takeaway from this troubleshooting was simple: when Veeam reports that a Hyper-V checkpoint operation has failed, don’t look only at Veeam. Try the operation directly from Hyper-V and understand what changed in the VM before the problem started.
In this case, that was exactly where the answer was.
