Safe to run this to delete an orphaned snapshot in HyperV

Question

Safe to run this to delete an orphaned snapshot in HyperV

Takami Chiro 311

HI everyone,

Hope you can help. A same orphaned snapshot issue happened again on the same vm on the same Hyper-V Host within 3 weeks.

I have checked the timestamp of the vhdx and avhdx. The vhdx stayed in the snapshot time which is this morning 10/01/2026 at 4am. The avhdx file, instead, is up to the current time and date.

Besides, I have run Get-VMSnapshot -VMName "myserver" and looks like the system can see the existence of the snapshot (does it count as orphaned because I just did not see the remove option in the menu?)

Now I would like to ask if it is safe to run this command (( Get-VMSnapshot -VMName "MyServer" | Remove-VMCheckpoint )) . I know it will merge the snapshot automatically before the snapshot removed).

Please advise. Thank you for your help in advance.

Takami Chiro

0 comments

2 answers

Your answer

Answer 1

Hi Takami Chiro,

Based on what you've described, this does not immediately sound like a true orphaned checkpoint, because Get-VMSnapshot -VMName "MyServer" is still able to detect the checkpoint object. In a genuinely orphaned scenario, Hyper-V is often unable to see the checkpoint in the management layer even though AVHDX files remain on disk.

The fact that the AVHDX file timestamp continues to update while the parent VHDX remains at the checkpoint creation time is normal behavior when the VM is actively writing to the AVHDX differencing disk. In this situation, using Remove-VMCheckpoint is generally the supported method because Hyper-V will schedule a merge of the AVHDX chain back into the parent disk rather than deleting the files directly.

Before proceeding, I strongly recommend verifying that the VM is healthy, that you have a current backup, and that there are no storage-related warnings in the Hyper-V-VMMS or Hyper-V-Worker event logs. If Get-VMSnapshot returns the checkpoint and there are no signs of AVHDX chain corruption, the command:

Get-VMSnapshot -VMName "MyServer" | Remove-VMCheckpoint

After running the command, monitor the merge process carefully. Depending on disk size and I/O activity, the merge may continue in the background for some time, and the AVHDX file may remain present until the operation completes. I would strongly advise against manually deleting any AVHDX files from disk, as doing so can result in virtual disk corruption and potential data loss.

One additional concern is that you've now seen the same issue twice within three weeks on the same VM and host. Once this checkpoint is resolved, I would investigate backup software, replication tools, and Hyper-V event logs to determine why checkpoints are being left behind repeatedly, as that is often a symptom rather than the root cause.

I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason

Answer 2

Yes. If Get-VMSnapshot -VMName "MyServer" returns the checkpoint, removing it through Hyper-V PowerShell is the supported approach.

Use the current cmdlet name:

Get-VMSnapshot -VMName "MyServer" | Remove-VMSnapshot

Key points for this case:

If Hyper-V can see the checkpoint in Get-VMSnapshot, it is not fully invisible to Hyper-V, even if the Delete option is missing in Hyper-V Manager.
Removing the checkpoint by cmdlet deletes the checkpoint through Hyper-V and initiates the required merge process.
Deleting the checkpoint does not discard the VM’s current state. Hyper-V merges the associated .avhdx data back into the parent virtual disk so the latest changes are preserved.
If multiple checkpoints are returned by Get-VMSnapshot, piping them to Remove-VMSnapshot processes all of them.

Recommended sequence:

Verify no backup job is currently running, because backup software commonly leaves stale or orphaned checkpoints.
Confirm the checkpoint list:

Get-VMSnapshot -VMName "MyServer"

Remove the checkpoint with:

Get-VMSnapshot -VMName "MyServer" | Remove-VMSnapshot

If removal does not complete, shut down the VM and retry. A shutdown can trigger an auto-merge if possible.
If it still fails, inspect the disk chain and merge .avhdx files manually only after backing up all files first.

Useful checks if this keeps recurring:

Check whether recent third-party backups completed successfully.
Verify backup software is cleaning up its checkpoints.
Check free space on the volume that stores .vhdx and .avhdx files; merges need sufficient free space.
Check for file locks from backup or antivirus processes.

Do not manually delete .avhdx files from disk. If manual repair is needed, back up all files first because checkpoint chain repair can risk data loss if done incorrectly.