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
Best Answer
The space savings are real. You can check the dedup ratio in Server Manager. Upgrading to 2012R2 and using deduplication has saved us from buying new storage for at least a year.
Don't try to add the logical file sizes and compare them with "Size on Disk" - the latter is only the sum of not deduplicated files/parts. Deduplicated data doesn't show up at all here. The free space of the volume can't be calculated that way, check properties of drive/volume.
This makes sense - when two files have 80% in common, what size on disk does each file occupy?
The background is that deduplicated parts (or whole files) are stored in the deduplication pool. The non-deduplicated parts of a file are stored as a sparse file with reparse points where the deduplicated parts are to be.
The dedup pool hides inside the System Volume Information folder - if you check its size you know what amount of deduplicated/compressed is stored on the drive. Add that to Size on Disk of your files and you'll be pretty close to actual volume utilization.
There's a pretty good primer from MS for this: https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/understand