This problem was first encountered on an IBM x3650 in a cluster with an IBM x3550 for failover, however this problem is reproducible on a server running HyperV not part of a cluster.
When I try to run a VM based backup from inside the VM using the server backup utility to E: drive(which is an attached vhdx file). It fails with this error
Backup failed to complete. There is not enough disk space to create
the volume shadow copy on the storage location. make sure that, for
all volumes to be backup up, the minimum required disk space for
shadow copy creation is available. This applies to both the backup
storage destination and volumes included in the backup. Minimum
requirements: For Volume less than 500 megabytes, the minimum is 50
megabytes of free space. For volumes more than 500 megabytes, the
minimum is 320 megabytes of free space. Recommended: At least 1
gigabyte of free disk space for each volume if the volume size is more
than 1 gigabyte. Detailed Error: Insufficient storage available to
create either the shadow copy storage file or other shadow copy data.
In the event viewer I see this error
EventID: 521 The backup operation that started at 'TIME’ has failed
because the Volume Shadow Copy Service operation to create a shadow
copy of the volumes being backed up failed with following error code
'0x80780119'. Please review the event details for a solution, and then
rerun the backup operation once the issue is resolved.
This problem was not happening in our test setup using Server 2012 R2 MSDN copy, before rolling out to production using our Volume license copy of server. So as a test I installed two VMs on a Host(MSDN) server running HyperV, one VM using our MSDN copy and one with our Volume license copy of server, very simple install, install Windows backup, attach VHDx file as E: dive and attempt bare metal backup. The MSDN copy is able to perform the bare metal backup. The Volume license copy fails with the above errors.
Has anyone else run into this problem? Or any ideas on where to look to see the differences between the two VMs that is stopping the backup from completing?
EDIT:
I have since verified this on two different servers, VM installed with MSDN copy of server 2012 R2 work for bare metal backups, VMs installed with purchased Volume license copies of Server 2012 R2 do not work for bare metal backups, another bit of info on the server that cant perform bare metal backups, its able to back up C: drive fine, its not until I hit bare metal back up that it fails.
I found this post which is similar to my problem I think, but when I tried his fix, and attempted to recover the VM the Windows PE System image recovery said it couldn't find a image to recover.
https://superuser.com/questions/663782/windows-8-1-insufficient-storage-available-to-create-shadow-copy
Best Answer
I am going to answer my own question in hopes it might help someone else. The problem had to do with windows trying to backup the recovery Volume which it has to do if you want to be able to do a full backup so you can perform a full bare metal recovery. The Volume did not have the required 50MBs of free space for the VSS backup to run and it was failing. I ended up having to make a small 500MB volume at the end of C to use for extra space, and use the vssadmin Add ShadowStorage command to tell it to use the extra space. You can read more details below and a link to a more detailed discussion on the technet forums here
http://social.technet.microsoft.com/Forums/windowsserver/en-US/7373a7b8-01c8-4e2b-aaaa-513b7dad56f4/windows-server-2012-r2-vm-back-up-fails-with-insufficient-storage-available-to-create-either-the?forum=windowsbackup#8aaa04ec-9a89-4599-80aa-b15c5d09651d
From testing I found that the disk management snap in was saying I had lots of free space on the recovery volume when I did not. I ran the powershell command Get-Volume and it shows the following for my recovery volumes in my test VMs I also used diskpart to assign a drive letter to the recovery drive so I could see its contents
HyperV VM Gen 2 Installed with MSDN, Recovery Volume Size: 300MBs, Free Space: 59.83MBs, Winre.wim file size: 215MBs BACKUPS WORK on this one.
HyperV VM Gen 2 Installed with Volume license copy Recovery Volume Size: 300MBs, Free Space: 30.24MBs, Winre.wim file size: 243MBs BACKUPS FAIL on this one.
HyperV VM Gen 1 Installed with Volume license copy System Reserved(AKA Recovery)Volume Size: 350MBs, Free Space: 61.07MBs, Winre.wim file size: 243MBs BACKUPS WORK on this one.
As you can see the MSDN copy has a smaller winre.wim file which allows the free space to be above 50MBs so you don’t get this error “For Volume less than 500 megabytes, the minimum is 50 megabytes of free space.”
When installing to the Gen 1 VM the Volume license copy makes a larger Recovery drive so the free space is above 50MBs however it fails to do this on Gen 2 VMs and the backups fail, is this a bug? Another small bit of info is the file size difference between the two server 2012 ISO files is about 28MBs exactly the difference between the two different winre.wim files.
To temporarily fix this problem I copied over the smaller winre.wim file from the MSDN VM to the Volume license VM and the backups work, they even work to do a complete recovery from, but at that point the Volume license ISO I am using to do the image recovery puts its larger winre.wim file back in and backups fail again the newly recovered VM.
I also tried the vssadmin resize shadowStorage command but it wouldn’t take the Volume IDs, so I had to assign them a drive letter and set its size to unbounded and the backups still failed.
I then FINALLY found that if I shrunk C drive down by 512MBs and created a new partition and added Shadow Storage to it with the following command, S being mapped to the recovery volume vssadmin Add ShadowStorage /For=S: /On=F: /MaxSize=UNBOUNDED The BACKUPS WORK!!
Finally the backups work however after recovering the new VM image the Add ShadowStorage Map is lost and has to be recreated for backups to work again. Not a great fix but better than nothing right now. Now my question is, will MS release a hotfix for this sometime soon?
Thanks Chris