Share via

Hyper-V checkpoints do not removed after veeam backup

A.HAN 1 Reputation point
Jan 11, 2022, 7:21 PM

Hello community,
Hope you all are doing well

I am facing a problem here in my Hyper-V server,we all know that after the VMs checkpoints created by the Veeam backup job are deleted after the job completion, my problem is that these checkpoints are not deleted after any job in some VMs, so after each daily incremental job they increased by 1, now I have about 5 checkpoints in each VM of those are facing the problem, and this is an issue for me it will be too much space taken after some weeks.

I am using Veeam Backup and Replication 11

So could anyone please help me to solve this problem?
I would really appreciate it.

Thank you all,

Hyper-V
Hyper-V
A Windows technology providing a hypervisor-based virtualization solution enabling customers to consolidate workloads onto a single server.
2,744 questions
0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. Limitless Technology 39,686 Reputation points
    Jan 12, 2022, 9:29 PM

    Hello anonymous user-4139

    This issue appears to be intermittent as the dates don’t indicate a predictable continuous increase such as daily or weekly. If you are using on or off host proxy processing for Hyper-V you could try the following:

    Check your Veeam logs for each date during the backup, the logs should indicate some form of access error or file lock. If the access error or file log appears to have nothing to do with why you can’t delete the checkpoints then I would attempt their removal via PowerShell. At best it will resolve it and combined with the above the problem is resolved, at worst it gives you an actual error as to why they cannot be deleted.

    Get-VMSnapshot -ComputerName "MyHyperVHost" -VMName "VMWithLingeringBackupCheckpoint"

    This shows you the checkpoint information (note it does not show you the XXX-AutoRecovery.avhdx” as a checkpoint.
    And then we simply run Remove-VMSnapshot

    Remove the lingerging backup checkpoint like you would a normal one
    Get-VMSnapshot -ComputerName "MyHyperVHost" -VMName "VMWithLingeringBackupCheckpoint" | Remove-VMSnapshot

    Hope this helps with your query!


    --If the reply is helpful, please Upvote and Accept as answer--

    2 people found this answer helpful.

  2. Michal Tomasek 11 Reputation points
    Nov 12, 2022, 6:52 AM

    Get-VMSnapshot -ComputerName "MyHyperVHost" | Remove-VMSnapshot -name "veeam*"

    Removes all veeam snapshots on all VMs.

    Better to run in foreach as it is IO intense disk operarion which could kill your disks IO

    1 person found this answer helpful.
    0 comments No comments

  3. Daniel Klobnak 266 Reputation points
    Nov 16, 2022, 10:58 PM

    I have a similar issue - I noticed four snapshots that have randomly been created over the last few months - but always related to a Veeam backup - which are recovery due to Veeam.
    I have seen both remove-vmsnapshot and merge-vhd
    in discussions
    thoughts as to best approach? Thank you.


  4. Daniel Klobnak 266 Reputation points
    Nov 23, 2022, 8:05 PM

    worked like a charm. Thanks.

    0 comments No comments

  5. LW 0 Reputation points
    Feb 17, 2023, 5:43 PM

    I ran into the same issue. Orphaned checkpoints named AVHDX not in the checkpoint inventory.

    I was ready to plan for downtime.

    Plan A was to shutdown the VM. Power it back up in hopes the merge process will start.

    Plan B was to merge the HDDs into a new VM.

    HOWEVER, doing a LIVE MIGRATION to another host fixed it. All of the AVHDX are now gone. I'm waiting to see if the backups screw this up again.

    I was surprised but my thinking in doing a Live Migration was to align the VM with the HOST and OWNER of the storage. I thought it would yield a better experience if I ended performing plan B.

    Try live migration to another HOST, can't hurt if you have a cluster.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.