We recently created a video on how to easily setup and operate MABS in which we explained the difference between Microsoft Data Protection Manager, Microsoft Azure Backup Service and the Microsoft Azure Backup Server (both confusingly accroymed MABS). Part of that video was created for a client who was having difficulties understanding the complexities of Microsoft Azure Backup Service (aka MABS, aka MARS).
Their big issue was that their shadow copies were consuming as much space as the administrator had configured to be available for VSS copies.
If you’re using Microsoft Azure Backup Server to manage Microsoft Azure Backup Service it will Create only temporary shadow copies and delete them after the backup has completed. However if you’re not using Microsoft Azure Backup Server and you are only using Microsoft Azure Backup Service the VSS Shadow Copies are flagged as persistent and they are not deleted until shadow copies run out of space and then only the oldest one is deleted to make space for the newest one.
This is obviously very confusing. Our client kept expanding the amount of space available to Shadow Copies and found that no matter what size they made it, it was filled up and MABS would throw an alert telling them that their shadow copy space was at 94% or some equivalently high number:
As you can see in the screenshot below, they had 206 Shadow Copies all marked as Persistent. If we tried to delete some of the Shadow Copies through command line it would error out telling us “Operation is not valid due to the state of the object”. When we looked that up we found that only the program that created the shadow copies has the authority to delete the shadow copies. In our case they were created by the VSS writer as commanded by MABS.
Here are some of the VSS commands you see above, in case you want to run them yourself:
#Delete ALL Shadow Copies
Get-WmiObject -List Win32_ShadowCopy | ForEach-Object { $_.CreateInstance().Delete() }
#Count the number of Shadow Copies
(Get-WmiObject -Class Win32_ShadowCopy).Count
#List all of the Details about Every Shadow Copy
$shadowCopies = Get-WmiObject -List Win32_ShadowCopy | ForEach-Object { $_.CreateInstance() } | Sort-Object InstallDate
#List Some of the Details about Every Shadow Copy
vssadmin list shadowstorage
After some significant troubleshooting we found that we were unable to clear this issue and called Microsoft technical support for help. Their MABS staff we’re also confused and eventually called in a VSS expert.
The Microsoft VSS expert told us that everything we were seeing was expected:
- MABServer creates only non-persistant Shadow Copies and automatically deletes them after they are copied to Azure
- MABService, creates only persistent Shadow Copies and does NOT delete them after they are copied to Azure
Fortunately there was an easy way to resolve our storage problem which was to:
- go into the configure Shadow Copies GUI by right clicking on the C drive and selecting Configure Shadow Copies
- setting the Shadow Copy Space to a much lower number
- In the first screen shot on this page you can see that it’s currently at 120,000 GB and we dropped it down to 20,000 GB
- Then click the Create Shadow Copy button
What that does is force the VSS writer to delete a pile of old shadow copies to make space for that single new one. As you can see in the second screenshot on this page, at the bottom that process reduced the number of shadow copies down to 22, and returned about 100GB to free space.
That was wonderful in that we got the space back but it did not solve the MABS alerts, indicating that the MABS was running low on Shadow Copy space.
We were surprised to find that there is no way to configure MABService thresholds for such space and that the answer is to just ignore them. There’s nothing to be done because VSS will correctly delete old Shadow Copies as MABService creates new ones.
The only alternative to this was to install Microsoft Azure Backup Server, which is free to manage the Microsoft Azure Backup Service aka MABS and MARS). If the Microsoft Azure Backup Server is used the volume shadow copies are transient because they’re marked as non persistent and deleted immediately after the backup service is completed.
0 Comments