A Guide to Volume Shadow Copy

Storage has always held a special place in my heart ever since I got my first real taste of it managing a large Windows network.  When I learned of snapshotting volumes on expensive NAS systems, I yearned for that ability in Windows.  In 2003, my wish came true when Microsoft introduced persistent Volume Shadow Copies for Server.  Since its release, it has been a must configure on any server involved with non-database data storage.

This article focuses on the Volume Shadow Copy service (sometimes referred to as VSS) and related tools that allow Windows to take make periodic backups of data stored on Windows Servers.  The service itself is also leveraged for other things, such as third party backup tools, Hyper-V Replica, and other products that need to access otherwise locked data.  This article will not cover those other scenarios in any depth.

How it Works:

Volume Shadow Copy is configured through the properties of any given physical disk in Windows Explorer or through the Computer Management System Tool for Shared Folders.

The default schedules are for 7:00 am and 12:00 noon on Weekdays only.  While you can adjust these using the Shadow Copy configuration interface, the schedules are, in fact, Scheduled Tasks - the configuration interface just builds the task for you.  (The task scheduler has no concept of holidays so if left to the defaults, you can expect the task to execute every Monday through Friday).

For existing snapshots, users (if instructed/permitted) can then access the "Previous versions" of a folder or file through the properties of that folder or file.  Otherwise, administrators can use the same interface to perform the recovery.

There are some important things to remember when implementing VSS:

• Snapshots apply to the entire drive and cannot be limited to a folder or file. 
• Snapshots are block level.  They do not backup the entire file, rather, they backup only the changed portion of that file (in most cases).
• While they ARE backups, they should not be relied upon as your only backup.  They are primarily intended to allow end users (optionally) and administrators easy access to recent copies of the file in the event of accidental deletion, corruption, or modification.  If the disk storing the VSS data fails, the copies cannot be recovered and as such, a more traditional backup is required!
• Snapshots may not be created when they are supposed to: if the disk is too busy, VSS will "cancel" the snapshot
• There is a limit to the number of snapshots that can be retained, based on both the number of snapshots and the total amount of allocated space for snapshots.

The VSS data is stored in System Volume Information and is not directly browsable.  Even if you adjust the access control lists to view the contents of the folder, because the data is based on block level changes, you won't find any files to open or other recognizable VSS data to access.

How to Setup:

Option 1: Open Computer Management, expand System Tools, and right click on Shared Folders and then expand All Tasks - the only menu option presented is Configure Shadow Copies...

Figure 1: Configuring Shadow Copies through Computer Management.

Option 2: Go to Windows Explorer and right click on any physical hard drive in the server, the menu should display with an option to Configure Shadow Copies...
Figure 2: Configuring Shadow Copies through the properties of a drive.

The configuration screen presented is the same for both options above:
Figure 3: The Shadow Copies configuration window.

To Enable Shadow Copies on a specific drive, you need to click on the drive and then click the Enable button.  BUT WAIT! Before enabling, if you want to place your copies on a different volume or better still different physical disk (recommended for heavily used file servers), you need to click on the settings button before any copies are created (enabling a volume will instantly create a copy).  

The settings windows allows you to change the location of the copies (unless copies already exist), the amount of disk space reserved for VSS copies, and the schedule for when copies will be made.

Figure 4: Shadow Copies settings for a given drive.

By default, Windows allocates about 10% of the disk space for VSS copies.  Remember, copies are not FULL copies of files, only changed blocks, so you can store many copies in relatively little space.

Managing From the Command Line:

As mentioned above, the Snapshots are created through a scheduled task.  That should set off a flag of recognition - that means that the copies are created through some kind of command or action. Which means you can control VSS through a command prompt.

VSSAdmin.exe and DiskShadow.exe are the two primary tools used for command line management.  The scheduled task contains the following command for creating the copies:

C:\Windows\system32\vssadmin.exe Create Shadow /AutoRetry=15 /For=\\?\Volume{GUID ID of the Volume}\

Both VSSAdmin and DiskShadow seem to function similarly, but DiskShadow is newer and appears better at deleting problematic shadow copies (generally created for other purposes, such as a Windows Backup or third party copy).  For example, in one instance, the following error was received:

Error: Snapshots were found, but they were outside of your allowed context.  Try removing them with the backup application which created them.

And VSSAdmin was unable to delete the offending snapshot while DiskShadow was.

For more information on these commands, open a command prompt and run the command with the /? switch or see the Additional Information section below.

Recovering Data (Reverting):

Once you have one or more copies to recover from, the administrator can chose to revert (note the Revert button in Figure 3 above) the entire disk (from the Configure Shadow Copies windows) or by right clicking on a file or folder and bringing up the properties of the object.  On the Previous Versions tab, you'll find a list of accessible previous versions and button options on the bottom to Open or Restore.

Figure 5: Previous Versions tab.

If you highlight the snapshot and open it, an Explorer Window should appear that looks like the folder contents but if you note the address bar, it indicates this is the folder as of a previous point in time.  From here, you can drag and drop out of the previous point in time to the current folder.  WARNING! I recommend performing your recovery and immediately closing the window so as not to confuse yourself as to what you are looking at.

Figure 6: Explorer window with from a previous point in time.

Moving Copies:

Once you've had VSS running and creating snapshots, you cannot move them.  If you decide you want to place them on a different disk, you need disable VSS for the volume (which will permanently remove all previous snapshots!) and then adjust the settings to place them on a different logical disk.  You cannot store VSS data on a network share - the disk must be local to the system.

Limitations:

Given the nature of databases, VSS is not really appropriate for use with them.  Though I still have my doubts that it caused any problems, I had one Access developer claim it was corrupting their multi-user database (Corruption did seem to lessen once disabled) but outside of that instance, I've never seen VSS cause issues. Further, SQL and Exchange databases would have many changes and restoring the file (assuming it could be easily opened by the database engine after the restore) would cause a great deal of lost data to most databases.  These applications should rely on more traditional backup systems.

As noted, by default VSS will only keep 64 snapshots of data, disk space providing.  This number can be increased to a maximum of 512 as noted in the Microsoft document Registry Keys and Values for Backup and Restore (though a subsequent comment suggests there may be a bug and the limit may be a slightly lower 500).  

Some of the registry options may not apply (or fully apply) to the VSS service as it relates to previous versions snapshots.

Enabling Shadow Copies on volumes using mount points will not enable the data within the mount points to be copied.  If you want the mount points copied, you need to enable Shadow Copies on the mounted volume itself.

With Server 2003, you could only restore files through network paths, in 2008 and later, you can access the previous versions tab while browsing the folders directly on the server.  While you should not be using 2003 any longer, one trick for accessing a file you might not otherwise have stored in a shared folder was to use the administrative shares - \\server\x$ - since VSS is VOLUME-wide, it would allow you restore any file on the entire drive even if that file was in a "parent" folder that wasn't shared.

Recommendations:

Ideally, if you can, place your VSS data on a separate physical disk (a VSS data drive).  Because the the copies are basically a database of block level changes, you will not be able to recover full files should the disk you're snapshotting fail, but this will offload the writes from the main drive to the VSS data drive.  Further, this VSS data drive need not be redundant.  For VMs, I typically try to create a separate virtual drive on non-redundant/less redundant storage where I place my pagefile and VSS data (as well as any other non-crtical information; storage is cheap, but it's not THAT cheap!)

If you are planning a file server and intend to use Volume Shadow Copy with it, use an allocation unit size of 16 KB or larger when formatting the volume. (note: you lose the file compression option when the allocation unit size is greater than 4 KB).  This can help prevent defragmentation passes from deleting older shadow copies sooner than expected.

Even though the copies are block level changes, smaller files and those blocks may still be recoverable.  For security reasons, you would still want to encrypt the storage holding the VSS data.

If you are taking snapshots of multiple volumes, try to schedule them at least 10 minutes off from one another.  Snapshots should complete faster and more reliably (especially if sharing a storage disk) if they aren't contending with one another for disk access.

Think about how your organization works.  Who does what when?  If you have multiple volumes and departments with different work schedules, you might find it makes sense to have an Accounting volume where the snapshots are at 10:30 am and 2:00 pm while the Marketing folks might work later in the day on occasion and need snapshots at 11:00 am and 4:00 pm.  While you CAN make snapshots hourly or even more frequent, each snapshot will put a load on the server when they occur.  And remember, you have a finite number of snapshots; default of 64 and a registry altered maximum of 512 which can shorten the history available to you.

Consider using DFS replicated storage to increase your snapshot count.  If you have DFS replicated data, you can enable snapshots with one schedule on one DFS server and another schedule on another.  For example, Server1 snapshots at 9:00 am and 2:00 pm while Server2 snapshots at 11:30 am and 4:30 pm.

Performance Note:

If the disk is too busy working on other requests, especially other copy creation requests, the snapshot may not take place.  When 2003 debuted end-user recoverable copies, I recall being told if the disk was too busy for VSS to work, the VSS service would not activate and you would not have a copy for that particular window of time. Unfortunately, in researching this article I could not get any confirmation of this from Microsoft nor could I find any documentation that verifies this.  Keep this in mind when implementing VSS in your organization.

Additional Information:

Volume Shadow Copy is supported when using Data Deduplication in Windows Server 2012 and later.

If you remove a volume that previously had Shadow Copies enabled, you should ensure the scheduled task that created the copy for that volume is deleted as well.  Otherwise, your event logs may start showing an Event ID 7001.

Do not restore a VSS volume to another volume on the same server.  This can cause unpredictable results because the Snapshot IDs will be same.  (For example, do not backup your server's D: drive and then restore it to a new E: drive on the same server without disabling Volume Shadow Copy first).

VSS as a technology has been incorporated into client versions of Windows for some time for features like System Restore.  Additionally, many third party backup utilities use it to perform backups and capture open files.  The ability to snapshot changes disk wide and in a similar manner to Windows Server, restore individual files and folder has not been exposed directly by Microsoft.  You may be able to simulate the the server functionality using the information found here.  There are also third party tools, such as ShadowExplorer, that allows you to explore each Snapshot for files to restore or just to see what versions you have available.

If you want to dive more deeply into the technology, how it works, and what you can do to customize it, the following resources may be of use to you:

• Volume Shadow Copy Service
  https://technet.microsoft.com/en-us/library/ee923636(v=ws.10).aspx
• Registry Keys and Values for Backup and Restore
  https://msdn.microsoft.com/en-us/library/windows/desktop/bb891959(v=vs.85).aspx
• VSSAdmin Command-Line Reference
  https://technet.microsoft.com/en-us/library/cc754968(v=ws.11).aspx
• DiskShadow Command-Line Reference
  https://technet.microsoft.com/en-us/library/cc772172(v=ws.11).aspx
• Best Practices for Shadow Copies of Shared Folders
  https://technet.microsoft.com/en-us/library/cc753975(v=ws.11).aspx

In Conclusion:

The Volume Shadow Copy Service and Previous Versions was a "must-have" feature and definitely a compelling reason to upgrade from Server 2000 to Server 2003 or later.  It's free, easy to setup, and immensely useful at times.  You should make it a point to configure it on any server and drive that handles file storage in your organization.