Windows Server Backup on 2012 R2 volume size limitations

You are right in your assumption that WSB has created shadow copies. It uses these copies to maintain a backup history.

If you still have backup versions (and thus shadow copies) of points in time before your dedup optimization job has run, you would not see any savings at all since the deduplicated blocks have not been freed - they are needed for an older, non-deduped version of the data which is still referenced by one of the shadow copies.

So the bottom line is that if you need deduplication savings to show, you need to remove all older shadow copies.

The increase you are seeing is probably not due to deduplication activity but simply due to the fact that additional backup jobs were run in the meantime and older shadow copies are not deleted unless necessary (i.e. the volume would not have enough space for the new backup otherwise)

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