The volume shadow service (VSS) has a storage limit on each volume. If it needs more space for a new snapshot, it deletes an old one. If you want to create a smarter space management algorithm, which also considers the size of individual snapshots, you’re in trouble, because getting the size is not documented anywhere. But now it is Image may be NSFW.
Clik here to view.
.
Image may be NSFW.
Clik here to view.
On this picture you can see the output of vssadmin.exe. I had two snapshots, and only the total storage area sizes can be displayed.
Image may be NSFW.
Clik here to view.
I knew my goal was achievable, because TimeTraveler (an awesome software which perfectly utilizes the possibilities of VSS) can show individual snapshot sizes, see picture on the right. But, sadly, there is no API for it according to MSDN.
Image may be NSFW.
Clik here to view.
With a little bit of reverse engineering and searching the web, I found out how it’s done: all VSS snapshots are actually stored as files in the System Volume Information folders. This folder contains a file named {3808876b-c176-4e48-b7ae-04046e6cc752}, which seems to be a VSS database, and other files with names that start with another GUID, followed by the GUID mentioned before. I had two snapshots, so I had two of these, the picture on the right shows their properties. As you can see, the file creation times and sizes correlate nicely with TimeTraveler’s information.
Matching these files with the snapshots is not trivial. The GUID’s in the file names are V1 (time and MAC address based), and they have nothing to do with the GUID’s of snapshots or snapshot sets, which are V4 (random). (You can read about GUID algorithms here.) The VSS database and storage files can’t be accessed by file system API’s in any way, not even by LocalSystem. I checked the database file with WinHex‘s disk editor anyway, and it contains the file name GUID’s, which I couldn’t find in the registry or anywhere else. So you can forget about accessing the VSS database. The best way I could think of is matching the file creation times with the VSS snapshot creation times, but there can be differences measuring a few seconds.
If you look closely, you might have noticed there’s a discrepancy: the file sizes add up to 365,41 MiB, and the vssadmin output reports that this is the allocated space, not the used space. The reason is simple: VSS uses copy-on-write, so when you modify files which exist in a snapshot, then the last snapshot will grow to preserve the original content. So I’m pretty sure that all but the last snapshots use all allocated space, and the last snapshot uses less, it makes perfect sense. Since there’s an API to query the total space, you can easily calculate the space actually used by the last snapshot, too.
By default, the System Volume Information folder is only accessible by the system account. Impersonating this user is my next post‘s topic, it would be an overkill in my case. The easiest way is to simply modify the DACL of this folder, luckily, administrators are allowed to do that at least. Another way is running your VSS software as a system service, just like TimeTraveler.
I originally planned to release source code as part of the Joco Library, but it would involve a lot of COM interop, hacking, and messing with privileges, which would be a nightmare to implement and unit test, and I decided that it’s not worth it. But if you can use the stuff I wrote, I’d like to hear about it.
