The Windows Volume Shadow Copy Service exists to produce clean snapshots of disk volumes, and to create shadow copies of data or files that are consistent, readable, and associated with some specific timestamp. Microsoft abbreviates this service as VSS, for some odd reason or another omitting the C, as in the command line program that manages its behavior: vssadmin.

Microsoft likes to call this service its backup infrastructure for Windows XP and Vista on the desktop, and versions 2003 and 2008 on the server side. Shadow copies offer special capabilities for modern Windows file systems. First, they capture consistent backups of open files and applications in use, so that work can proceed even while a backup is underway. Second, they provide access to multiple copies of shared folders so that users can recover deleted files without administrator assistance, and enable desktop users to access prior versions of files when shadow copies exist. Third, they enable creation of transportable shadows for speedy network delivery so that a server backup image can more efficiently traverse the network from its source to a server with a tape backup unit for archiving and storage. Fourth and last, shadow copies support fast recovery of damaged files or volumes for Active Directory, Exchange, and other server applications to help users cope with hardware failures, storage problems, or software corruption issues.

Modern Windows versions make shadow copies more frequently than tape backups, and VSS stores shadow copies inside opaque file containers in the System Volume Information directory on any given NTFS drive. Here’s a listing that seems totally mysterious, until you understand that most of these files, especially the biggest ones, are shadow copies of some kind. (I’ll remark further on some of these files after said listing; these cryptic filenames have been abbreviated—their names aren’t human-readable anyway so it doesn’t matter anyway.) But it’s also worth remember that another kind of file resides in this directory—namely, restore points. These are generally much smaller (2 to 7 GB) and are gathered more often than backups, shared folder snapshots, or big file transfers. They’re also invariably fairly recent in date, because the Restore Point system tracks its space consumption carefully and deletes older restore points as it creates new ones to keep such consumption under control.

D:\ > dir “System Volume Information” /all
Volume in drive D is ESata750
Volume Serial Number is 626A-7D09

Directory of d:\System Volume Information

07/09/2008  10:53 AM    <DIR>          .
07/09/2008  10:53 AM    <DIR>          ..
02/05/2008  10:38 AM            20,480 tracking.log
04/20/2008  07:14 PM    21,939,716,096 {03bc0e88-001a4d49dd1e}{-04046e6cc752}
03/08/2008  12:07 AM     3,119,677,440 {04094e9b-001a4d49dd1e}{-04046e6cc752}
07/09/2008  10:53 AM     7,869,202,432 {24d3f234-001a4d49dd1e}{-04046e6cc752}
02/05/2008  12:05 AM            65,536 {3808876b-04046e6cc752}
03/05/2008  12:25 PM     8,575,565,824 {3efe9665-001a4d49dd1e}{-04046e6cc752}
07/10/2008  05:26 PM     2,202,009,600 {4a0df58d-001a4d49dd1e}{-04046e6cc752}
04/03/2008  02:59 PM     5,293,932,544 {53de1d25-001a4d49dd1e}{-04046e6cc752}
04/21/2008  12:50 AM        33,816,576 {69ab30d6-001a4d49dd1e}{-04046e6cc752}
05/03/2008  11:04 PM    84,038,152,192 {69ab3128-001a4d49dd1e}{-04046e6cc752}
06/06/2008  05:50 PM    12,775,100,416 {6b0f8a8f-001a4d49dd1e}{-04046e6cc752}
02/07/2008  12:19 AM    67,853,320,192 {8f12fcd0-001a4d49dd1e}{-04046e6cc752}
06/12/2008  11:02 PM     3,623,780,352 {ab268dd3-001a4d49dd1e}{-04046e6cc752}

13 File(s) 217,324,359,680 bytes
2 Dir(s)  376,944,144,384 bytes free

Check out the size for some of these files! When I looked at them, I noticed that the 80-odd GB file dated 5/3/2008 corresponded to my copy of my complete digital music collection to that drive, while the 60-odd GB item on 2/7/08 corresponds to my first image backup of the system to which this drive was attached. My observation is that when you backup, create a shared volume, or do any kind of massive file transfer onto a drive, VSS creates a shadow copy at about the same time NTFS creates the original copy. What’s upsetting as well as interesting here is that although MS indicates about 15% of a volume’s storage space is typically allocated for shadow copies, this collection is over 200 GB, and consumes nearly 29% of the total drive space!

I did a little reconnoitering and observed the following shadow space consumption for all SATA drives on my system (shadow copies only occur on direct attached drives, not on USB-attached ones, which helps me understand why USB drives are recommended for backup storage):

Table of Shadow storage info from my system

Drive     Total        Used      Shadow    %-age    %-age
                                           used     total

C:    298 (320) GB   89.3 GB   41.845 GB   46.0    14.04%
D:    698 (750) GB  349.0 GB  202.399 GB   58.0    28.99%
F:    149 (160) GB   23.0 GB   10.144 GB   44.1     6.81%

What I infer from the data shown here is that Windows Vista generally stays within the 15% limit for shadow copies, but that big backups or file copies can exceed those bounds. From the directory listing above, in fact, it’s pretty clear that backups (the 21 GB file), big file transfers (the 84 GB wholesale transfer of digital music to this drive), and a disk image of the parent system (the 67 GB file dated 2/7/08) caused VSS to blow its storage limits right past the ceiling. I’m not wild about maintaining extra copies of stuff I’ve also got stored elsewhere (as is the case with all three of the aforementioned items, one of which backs up a system with mirrored drives), and I’m not wild about giving up 30% of my drive’s storage space for a form of data and files insurance.

That’s what led me to Microsoft’s vssadmin command line program. This utility lets users with administrative privileges inspect and manage VSS behavior on an XP, Vista, or Server 2003/2008 PC. Here’s what the basic help for vssadmin looks like, and provides a nice overview:

c:\>vssadmin /?
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

—- Commands Supported —-

List Providers – List registered volume shadow copy providers
List Shadows – List existing volume shadow copies
List ShadowStorage – List volume shadow copy storage associations
List Volumes – List volumes eligible for shadow copies
List Writers – List subscribed volume shadow copy writers
Resize ShadowStorage – Resize a volume shadow copy storage association

c:\>

By running vssadmin list shadows and vssadmin list shadowstorage, you can determine how many shadow copies you’ve got out there, and where they reside. You can also navigate into the Volume System Information directory for each drive, and take inventory of those otherwise inaccessible files (which include all shadow copies on that drive). Then, you can use the vssadmin resize shadowstorage command to lower the ceiling on allowed shadow storage for the drive if you like. For the 750 GB D: drive used to create the directory listing shown earlier in this story, I decided to put a 50GB limit on that space, which got rid of all three of the big shadow copy files shown in the original directory listing.

For any of the various vssadmin subcommands you can get precise syntax directives and more descriptive data by typing vssadmin <subcommand> /?. For the all-important Resize ShadowStorage subcommand, that produces the following listing:

 

c:\>vssadmin resize shadowstorage /?
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Resize ShadowStorage /For=ForVolumeSpec /On=OnVolumeSpec [/MaxSize=MaxSizeSpec]

– Resizes the maximum size for a shadow copy storage association between
ForVolumeSpec and OnVolumeSpec.
– Resizing the storage association may cause shadow copies to disappear.
– If MaxSizeSpec is not specified, there no limit to the amount of space
it may use.
– As certain shadow copies are deleted, the shadow copy storage space will
then shrink.
– MaxSizeSpec must be 300MB or greater and accepts the following suffixes:
KB, MB, GB, TB, PB and EB. Also, B, K, M, G, T, P, and E are
acceptable suffixes. If a suffix is not supplied, MaxSizeSpec is in bytes.

 

Example Usage: vssadmin Resize ShadowStorage /For=C: /On=D: /MaxSize=900MB

c:\>

I used the command

vssadmin resize shadowstorage /For=D: /On=D: /Maxsize=50GB

to cut the shadow storage area down from its original allocation of 250 GB to 50 GB to get rid of the biggest files therein. Then I bumped the value back up to 15 percent of the 700GB actually present on the drive, or 105GB, by repeating the preceding command except for this argument in the final position: /Maxsize=105GB. I figure if Microsoft says 15% is the optimal amount for shadow copy storage on an NTFS drive, who am I to argue without a special need to so? I’ve got the space on the drive, so I just went back to what the normal limit is supposed to be, once I’d flushed the great big shadow copies that apparently got me into storage trouble in the first place.

You might want to conduct a similar exercise on your XP, Vista, or Server 2003/2008 direct attached drives, and see what you find. If any of the shadow copy stores exceed 15% of the total disk space available it should be OK to trim them down, though I’d be less inclined to do this on a server than a desktop. Also, please use the maximum storage from the Properties window in Explorer to figure your maxsize value, not the manufacturer’s disk sizing. When stating disk sizes, vendors report byte counts in decimal, and call 1,000,000,000 bytes a Gigabyte (the binary number is actually 1,024 MB), thereby inflating apparent disk sizes. Thus, for example, Seagate claims my D: drive is 750 GB because its maximum size is 750,000,000,000 bytes. But when translating that into binary it drops to 698 GB, which I rounded to 700 to make things easy for myself when calculating the maxsize value at 105GB. You should do likewise.

One more thing: the next time your system starts up, CHKDSK may kick in to inspect and repair the drive whose shadow copy storage allocation you resized. This is OK if it happens, and should be allowed to proceed to a successful completion.