Using the Windows Volume Shadow Copy Service (VSS)

Having just written an article about how to get items back from a volume shadow copy, I thought I should make some notes about how VSS works, how to configure it, and actually get VSS to create you some shadow copies! This is also useful because, on a filer server, it enables users to recover their own accidentally deleted or overwritten files and folders via the Previous Versions feature.

If you’ve never come across VSS before, TechNet has this to say:

Shadow Copies of Shared Folders provides point-in-time copies of files that are located on shared resources, such as a file server. With Shadow Copies of Shared Folders, users can view shared files and folders as they existed at points of time in the past. Accessing previous versions of files, or shadow copies, is useful because users can:

  • Recover files that were accidentally deleted. If you accidentally delete a file, you can open a previous version and copy it to a safe location.
  • Recover from accidentally overwriting a file. If you accidentally overwrite a file, you can recover a previous version of the file.
  • Compare versions of a file while working. You can use previous versions when you want to check what has changed between two versions of a file.

It’s probably something you want, assuming you have a bit of space somewhere to hold them. Note that due to how they work, a shadow copy only uses the amount of space necessary to hold the changes made to the volume. When you view the shadow copy, you’ll see the complete volume as it was when the shadow copy was taken, but behind the scenes the space used by that shadow copy is not that of a complete copy of the volume at that point in time.

You can store your shadow copies on a different volume. This can be a good idea, as otherwise the volume free space can seem to mysteriously vanish. However, the shadow copy volume possibly needs to be the same size or larger than your data volume as it has to hold a copy of all the changed data blocks from the data volume, which depends on the rate of change and how often you create shadow copies. You might also want to read the article Designing a Shadow Copy Strategy, which is old but still relevant.

Configure VSS for a file server

I’m doing this on Windows Server 2008 R2, just because that’s what my test VM is running. This stuff works back as far as Server 2003 though (but of course you’re not still using that in 2016…).

My server has a 40GB D drive for data and I’ve added a 40GB V drive for VSS use. As this ia a VM, I’ve done both of these as thin provisioned disks from VMware.

I’m running all the commands from an administrator command prompt, which vssadmin requires. I’m using Windows ISO files for the data. There is currently no shadow storage configured, and the drives have been freshly formatted:

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

No items found that satisfy the query.

C:\>dir d: /a
 Volume in drive D is Data
 Volume Serial Number is 1863-3C01

 Directory of D:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  11:25              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  42,851,102,720 bytes free

C:\>dir v: /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of V:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  11:24              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  42,851,102,720 bytes free

So now we’ll configure V: to be the shadow storage for D:, and to use the entire V: drive for that purpose:

C:\>vssadmin add shadowstorage /for=d: /on=v: /maxsize=unbounded
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Successfully added the shadow copy storage association

Now we’ll copy some data onto D:, and then check the space usage on D: and V: again:

C:\>dir D: /a
 Volume in drive D is Data
 Volume Serial Number is 1863-3C01

 Directory of D:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  11:25              System Volume Information
28/02/2011  12:41     3,181,234,176 Windows 7 Enterprise x64 English SP1 (X17-27625).iso
28/02/2011  12:38     2,433,157,120 Windows 7 Enterprise x86 English SP1 (X17-27617).iso
               2 File(s)  5,614,391,296 bytes
               2 Dir(s)  37,236,707,328 bytes free

C:\>dir v: /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of V:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  11:24              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  42,851,102,720 bytes free

As expected, there has not been any data used on V: yet.
Now let’s create a shadow copy of D:

C:\>vssadmin create shadow /for=d:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Successfully created shadow copy for 'd:\'
    Shadow Copy ID: {bbec09d9-3ed2-40b0-943d-5b459976fb80}
    Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

And we can see more detail about the shadow copy:

C:\>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Contents of shadow copy set ID: {2d629a37-10e0-4fb4-bf45-e0702de26f50}
   Contained 1 shadow copies at creation time: 28/01/2016 12:40:16
      Shadow Copy ID: {bbec09d9-3ed2-40b0-943d-5b459976fb80}
         Original Volume: (D:)\\?\Volume{cadd2f53-ba6b-11e5-93f2-005056a200aa}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         Originating Machine: VSSTEST.rcmtech.co.uk
         Service Machine: VSSTEST.rcmtech.co.uk
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessible
         Attributes: Persistent, Client-accessible, No auto release, No writers, Differential

Now the space usage on V: is:

C:\>dir V: /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of V:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  12:40              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  40,737,103,872 bytes free

So the space has dropped by about 2GB. VSS stores its data inside the System Volume Information folder, which by default only the local SYSTEM account has access to. So that we can see what’s going on, I’ve given myself access to this folder – but you shouldn’t normally mess with it.

C:\>dir "v:\System Volume Information" /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of v:\System Volume Information

28/01/2016  12:40              .
28/01/2016  12:40              ..
28/01/2016  11:24            20,480 tracking.log
28/01/2016  12:40            65,536 {3808876b-c176-4e48-b7ae-04046e6cc752}
28/01/2016  12:40     2,113,929,216 {db3a43f3-c5b1-11e5-88bc-005056a200aa}{3808876b-c176-4e48-b7ae-04046e6cc752}
               3 File(s)  2,114,015,232 bytes
               2 Dir(s)  40,737,103,872 bytes free

Note how the timestamp of the two files with GUIDs as their names matches when the shadow copy was taken. Note however that the GUIDs don’t match those reported via the vssadmin command…!
So let’s add some more files to the data drive. Clearly the free space drops on D:, but there are no changes to V: as we’ve not changed any blocks covered by our shadow copy:

C:\>dir d: /a
 Volume in drive D is Data
 Volume Serial Number is 1863-3C01

 Directory of D:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  12:40              System Volume Information
28/02/2011  12:41     3,181,234,176 Windows 7 Enterprise x64 English SP1 (X17-27625).iso
28/02/2011  12:38     2,433,157,120 Windows 7 Enterprise x86 English SP1 (X17-27617).iso
29/04/2014  10:34     3,234,070,528 Win_Ent_8.1_32BIT_English-Custom.ISO
24/04/2014  14:47     4,274,061,312 Win_Ent_8.1_64BIT_English-Custom.ISO
               4 File(s) 13,122,523,136 bytes
               2 Dir(s)  29,728,509,952 bytes free

C:\>dir v: /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of V:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  12:40              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  40,737,103,872 bytes free

Let’s see how that changes if we take another shadow copy:

C:\>vssadmin create shadow /for=d:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Successfully created shadow copy for 'd:\'
    Shadow Copy ID: {9f1f3eef-7e0d-4f55-ab72-3ed5ed2871cb}
    Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2

C:\>dir v: /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of V:\

28/01/2016  12:29              $RECYCLE.BIN
28/01/2016  12:40              System Volume Information
               0 File(s)              0 bytes
               2 Dir(s)  40,736,202,752 bytes free

No real change there, only a slight drop. What’s happened in the System Volume Information folder?

C:\>dir "v:\System Volume Information" /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of v:\System Volume Information

28/01/2016  12:52              .
28/01/2016  12:52              ..
28/01/2016  11:24            20,480 tracking.log
28/01/2016  12:40            65,536 {3808876b-c176-4e48-b7ae-04046e6cc752}
28/01/2016  12:52           901,120 {db3a43f3-c5b1-11e5-88bc-005056a200aa}{3808876b-c176-4e48-b7ae-04046e6cc752}
28/01/2016  12:52     2,113,929,216 {db3a4401-c5b1-11e5-88bc-005056a200aa}{3808876b-c176-4e48-b7ae-04046e6cc752}
               4 File(s)  2,114,916,352 bytes
               2 Dir(s)  40,736,202,752 bytes free

There’s a new small-ish file created when we took the last shadow copy, and the larger file has also been updated.
Now we’ll see how VSS handles some data drive changes. Let’s delete some of the files from D: and then copy some new ones onto it, and see how the free space on the two drives looks:

C:\>dir d: /a
 Volume in drive D is Data
 Volume Serial Number is 1863-3C01

 Directory of D:\

28/01/2016  12:29              $RECYCLE.BIN
13/08/2009  10:08     2,996,799,488 Server 2008 R2 x64 (X15-59754).iso
02/03/2011  14:41     3,166,720,000 Server 2008 R2 x64 SP1 (X17-22580).iso
28/01/2016  12:40              System Volume Information
29/04/2014  10:34     3,234,070,528 Win_Ent_8.1_32BIT_English-Custom.ISO
24/04/2014  14:47     4,274,061,312 Win_Ent_8.1_64BIT_English-Custom.ISO
               4 File(s) 13,671,651,328 bytes
               2 Dir(s)  29,179,383,808 bytes free

C:\>dir "v:\System Volume Information" /a
 Volume in drive V is VSS
 Volume Serial Number is 7468-48AD

 Directory of v:\System Volume Information

28/01/2016  12:52              .
28/01/2016  12:52              ..
28/01/2016  11:24            20,480 tracking.log
28/01/2016  12:40            65,536 {3808876b-c176-4e48-b7ae-04046e6cc752}
28/01/2016  12:52           901,120 {db3a43f3-c5b1-11e5-88bc-005056a200aa}{3808876b-c176-4e48-b7ae-04046e6cc752}
28/01/2016  12:59     3,523,215,360 {db3a4401-c5b1-11e5-88bc-005056a200aa}{3808876b-c176-4e48-b7ae-04046e6cc752}
               4 File(s)  3,524,202,496 bytes
               2 Dir(s)  39,326,916,608 bytes free

There were no changes when the two Windows 7 ISOs were deleted, but as you can see, the large file in V:\System Volume Information has grown quite a bit after the two new Windows Server 2008 R2 ISOs were added.
Whilst copying the new ISOs, I had Performance Monitor (perfmon) running to monitor disk reads and writes on D:, and disk writes on V:. The activity was interesting. As expected we have plenty of write activity to the data drive:data disk writes

There’s also quite a bit of read activity on the data disk:
data disk reads

Which corresponds to write activity on the VSS disk:
vss disk writes

So we can actually “see” VSS reading the blocks about to be overwritten on the data drive and writing them onto the VSS drive to preserve them for the shadow copies.

In order to access the data in the shadow copies, you can go via the GUI – just right-click the drive or a folder or file and select Properties – Previous Versions. This also works remotely if the drive or folder is shared.

previous versions

Alternatively, you can create a symbolic link to the shadow copy.

More about how VSS works

VSS operates at the block level, and uses a “copy on first write” principle to keep the data safe: when the blocks used on the data volume that are included in a shadow copy are about to be overwritten, it copies them to the shadow copy volume to enable the shadow copy of the data volume to remain intact.

Note that if you lose the data drive or the volume shadow copy drive, you will lose access to your shadow copies. Shadow copies are thus not a replacement for a proper backup regime, they instead complement it.

Also, if the data drive goes offline, but comes back online again, the GUI access to previous versions seems to break. The GUI just shows There are no previous versions available. The vssadmin command does still show the shadow copies though. To fix this, restart the Server service (aka lanmanserver).

VSS manages the space usage on the shadow copy volume by removing older shadow copies to make room for new ones as necessary. Note that many backup applications make use of VSS, and thus temporarily create shadow copies. These are then removed once the backup operation is finished, but can cause some/all of “your” shadow copies to be lost due to their temporary space usage. If the shadow copy volume is too small to hold a temporary shadow copy, the backup will fail.

Because VSS monitors changes at the block level (not the file level), disk defragmentation software can cause your shadow copies to be lost. The shadow copy volume watches all the block changes the the defrag has to do and thus might have to remove some/all of your shadow copies to keep track of those changes. Some defrag software, e.g. PerfectDisk, has a VSS compatibility setting to help with this. It is most problematic if your cluster size is less than 16KB, because this is the size that VSS uses internally and is thus unable to tell if the defrag IO is different to normal IO.

 

 

This entry was posted in Security, Storage, Windows and tagged , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s