Warning! Volume Shadow Copy Service Sometimes Eats Excess Disk Space

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


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


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.


5 thoughts on “Warning! Volume Shadow Copy Service Sometimes Eats Excess Disk Space”

  1. if i am correct if you wish to store multiple system images the showstorage needs to be large on unbounded.

    i set my external 6tb drive to unbounded but it will still only make one system image file.
    i know in past i did some combination and it allowed multiple images to be stored.

    i have a c: ssd op system
    D: programs mainly
    e: data drive
    y: external 1
    z: external 2
    y and z are unbounded.
    i thought that when i run win 7 backup and restore version on 2in 10 it would create multiple system images and not just store the one.
    it did work at one point but no longer works and can not find correct settings using vssadmin to do it
    the for and on is confusing
    as it says for can be one drive like c: and on be drive d:
    however this does not work on eternal drives connected via usb sen as guid gpt partion ntf format same as other drives.
    eexternals are 6tb each.
    internals are 2 x 1tb and a 256gb ssd.

    if i try vsadmin for c: on z it fails and if i try it vice versa it fails command.

    so how can i get it so external drives will take as many backupops and as many system images as space for.

    it has been setup this way before but can not get it back. i dont want to rename folders or use other software as issues in renaming and other software images not always recognised by windows recovery process.

    1. Hmmm, interesting. Haven’t tried to mess with this for a while. I usually just move images that I want to keep to a different drive, so I have the most current one where vssadmin thinks it is, and others elsewhere I can work with if and when I should need them. Now that Win10 stores image backups in vhdx format, it’s easy to mount them as virtual drives and muck around inside them to your heart’s content. So that’s how I roll with that stuff.
      I don’t have time to research your question until after Thanksgiving in early December. If I can learn anything useful I’ll get back to you then. In the meantime, you may want to take this question to TenForums.com, where other experts — some more knowledgeable about VSSadmin than I am — may also be able to help you out.
      Thanks for posting,

  2. Hi Ed,

    I am having issue in one of the Drive space issue.I noticed system volume information folder having system files which is eating up space. I can see shadow copy is not configured on this drive and its disabled…Driv eis of 20 GB an these files tkaing almost 17 GB soace …Not sure what all those files and can those be deleted or not…Pls advice how to del those files…

    1. Dear Mohammed:
      I need to know more about what’s in that “mystery space.” Download and run the Open Source/SourceForge software package WinDirStat and install it on your PC. Right-click the exe file name (windirstat.exe) and click “Run as adminsistrator”. This should tell you more about what’s going on for that drive. If you like you can e-mail a screen capture of the WinDirStat tree map and file list so I can look it over and make some recommendations. My email address is ed at edtittel dot com, with the necessary substitutions.

  3. Hello Ed,
    I noticed this is a 10-year old article, but still useful nevertheless.

    You have mentioned this above:
    > 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.

    I have noticed that when my backup program reads a big file opened via VSS, there’s a huge read & write activity on the harddisk. Using the Resource Monitor tool, it’s clear that VSS is creating a copy of that file, even though it’s not really being written to by other applications.
    And I came here looking for an answer to why VSS writes so much data to the shadow storage even when the original file is not being actively modified (it’s possibly just open in Random mode, but there’s no activity from the application with the original file handle).

    Have you gained new information, or managed to find out anything new about this point?

    Thanks and regards

Leave a Reply

Your email address will not be published. Required fields are marked *