This particular machine has a pretty simple backup setup: a Windows Server 2012 R2 host with two 2012 R2 guest VMs. Integration services are installed on the two VMs and Backup (volume checkpoint) is enabled on both VMs in the integration services settings. Windows Server Backup is installed on the host, and it’s configured to back up the VMs and host system state to an external drive once daily.
This server was not completing backups for one virtual machine. The other virtual machine was backing up properly on this host.
I took a look at the event logs to find any clues as to why the backup might be failing for this particular VM. One particular event stood out for me.
Log Name: Microsoft-Windows-Hyper-V-Worker-Admin Source: Microsoft-Windows-Hyper-V-Worker Date: 4/17/2018 9:00:43 PM Event ID: 3280 Task Category: None Level: Error Keywords: User: NT VIRTUAL MACHINE\94FEE3F0-459E-498D-96E4-BF8272BAC254 Computer: HV01 The description for Event ID 3280 from source Microsoft-Windows-Hyper-V-Worker cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: DC2 94FEE3F0-459E-498D-96E4-BF8272BAC254 %%2147942480 0x80070050 The locale specific resource for the desired message is not present
Unfortunately, the event log didn’t give much information other than some error codes at the bottom of the event. Looking at the 0x80070050 error, that code means “The file exists”. (to find that, you can either Google the code, or you can use this guide to find out what the code means).
To figure out why “The file exists” matters, we need to understand how the backup process works when a backup is taken of a VM. Very roughly speaking, when a backup is created of a virtual machine, the host creates a checkpoint of the VM. The checkpoint creates a differencing disk (AVHDX) linked to the original VHDX. The parent VHDX is then backed up/copied. Once the backup is completed, the host merges the differencing disk back into the parent VHDX, and eliminates the checkpoint.
When Windows Server backup tries to create a checkpoint of the VM, it creates a differencing disk (AVHDX) which is the name of the original VHDX file with “-AutoRecovery” appended to the end of the file name.
In this particular case, there was an old AVHDX file that existed for that VM already. That must be what’s causing our “The file exists” error!
Before we just get rid of it, I went to the HyperV settings of the VM to see if it was in use.
If the AVHDX were in use, we would see it here instead of the regular VHDX file. The AVHDX file was not in use on this VM, and that AVHDX file had not been modified in a long time, so I deemed it safe to rename/delete it. After I deleted the file, I let the backup schedule run its course.
Nigmenog.com 
Hey, for me, it didn’t worked. Any ideas?
LikeLike
Thanks! I have been troubleshooting the vss writers but this article was the solution I was looking for!
LikeLike
Thanks for the really easy solution to nasty problem with Veeam Backup – chasing down the true error buried down lots of VSS writers/providers leading to a really simple solution: file already exists! 😒
LikeLike
This fixed my issue, Thank you
LikeLike
Muito Obrigado pela ajuda, depois de muita busca o seu post resolveu meu problema!
LikeLike
I had two VM’s located in the same folder, of which one backed up and the other did not. After hours of researching all these articles about it being a permissions issue, or VSS — which to me seemed very unlikely because my other VM in the same folder backed up just fine and then I stumbled across this article. I notice I did have an old AVHDX auto-recovery file where I my virtual disks were stored as your article details. I checked it, deleted it — (also had to remove a “pass-thru” drive) and viola, fixed. Thanks for the article as I was initially reticent to delete the recovery file in fear of corrupting my VHDX which I had taken note of before seeing this. Many thanks!
LikeLike