Looking at Common VSS Myths

Looking at Common VSS Myths

June 11

Microsoft aims to give business users peace of mind with BDR-friendly features such as Volume Shadow Copy Service or VSS. Bundled into Windows desktop and server editions, VSS allows users to easily make snapshots and backups of files in applications such as SQL Server, SharePoint, and our good buddy Exchange Server.

Despite being a very handy utility, there are many who feel that VSS has a number of vulnerabilities. We’ll take a look at some of the common VSS myths we’ve heard about, and then we’ll give you the full story.

Myth: VSS has sluggish performance. One advantage of VSS is that it generally takes snapshots without slowing things down too much. However, it has a history of dragging along taking snapshots of large volumes of data such as the amount you have on your hands in the typical Exchange environment.

The real story:  In my experience, VSS works as it should. VSS has specific response time requirements. If exceeded, these thresholds require VSS to release resources back to the OS and running applications. For example, see steps 5 and 6 in Microsoft’s TechNet article on creating Shadow Copy snapshots. The bolded information illustrates my point:


  1. The Volume Shadow Copy Service tells the writers to quiesce their data and temporarily freeze requestor (application) I/O write requests (I/O read requests are still possible) for the several seconds required to create the shadow copy of the volume or volumes. The application freeze is not allowed to take longer than 60 seconds. The Volume Shadow Copy Service flushes the file system buffer and then freezes the file system, which ensures that file system metadata is written and that the data is written in a consistent order.


  1. The Volume Shadow Copy Service tells the provider to create the shadow copy (a maximum of 10 seconds).

This information illustrates the time constraints in which VSS can work. The VSS process cannot exceed these limits, though it may use very little or all of the time allowed before the limit is exceeded. Typical time issues occur when this small amount of time is too long for a production application.

Myth: VSS commonly produces failures: If you’ve ever used VSS before, you’re probably familiar with the dreaded “Backup aborted! – Failed to Create Volume Snapshot …” error. This error and others pop up all too frequently and have a wide range of causes.

The real story:  There are specific rules that govern activity within the OS. This is why it is called an “operating system”. When an event occurs outside the bounds of those rules then an error is thrown. Typically an error like the one described above refers to a situation where VSS was not able to successfully create a snapshot. Without knowing the specific cause of this error, users are left guessing about valid reasons why this error would occur.

The reason for this type of error varies, though typically they have to do with conflicts between one or more installed software. For example, an anti-virus software that stops OS activity while checking files for virus patterns may require a priority level access over other applications within the operating system. This affects backup systems which leverage VSS and are bound to complete processes within the given time limits. Basically, VSS will only work with one process at a time so if two processes are requesting VSS services one of the processes will probably have problems. When conflicts like this are discovered, most software vendors will work to patch/fix their application to work with other applications.

Myth: VSS can lose data. VSS is capable of only storing 64 copies per volume, which sounds like a lot, but really isn’t when considering how many copies you’d have if you backup regularly, and/or use the feature for apps other than Exchange. Once that quota is reached, older copies are automatically deleted, opening up the potential for data to be lost if administrators aren’t careful.

The real story: The above myth is a bit misleading. The title suggests that the VSS process loses data due to an inherent limitation in the number of snapshots stored. Instead, here’s a better representation (Wikipedia) of what actually happens:

The creation of persistent snapshots (multiple snapshots which remain available across reboots until specifically deleted from the system) has been added in Windows Server 2003, allowing up to 512 snapshots to exist simultaneously for the same volume. In Windows Server 2003, VSS is therefore used to create incremental periodic snapshots of data or deltas (differences) of changed files over time. A maximum of 64 snapshots are stored on the server and accessible by clients or on the same server through network shares. This feature is known as Shadow copies for Shared Folders and is designed for a client–server model. The Shadow copies for Shared Folders client is required to be installed on Windows 2000 and Windows XP RTM and SP1. A copy of this client for 32-bit Windows platforms is available on the server or downloadable from Microsoft. It is built into the OS beginning with Windows XP SP2.

This reference shows that there are up to 512 persistent snapshots allowed as well as 64 incremental snapshots. So even if we’re only looking at data storage capacity in terms of the number of snapshots available, we’ve just increased the number of recovery points by almost 10 times. Another thing to consider is that snapshots are not intended to be permanent copies of system state. In fact, most backup software vendors leverage these snapshots to create backup files which are then written to permanent storage elsewhere. These same backup software processes will also manage the available cache of snapshots and clear those snapshots which are successfully stored elsewhere.

The above practices do not imply any valid reason for “lost data”, and in fact, they imply a well-thought-out process whereby Microsoft or any other backup software vendor can use a standard and reliable technology employed for the purpose of providing historical disk image data over time. To me, this method suggests that data is preserved rather lost.

Fact: VSS is not a one-stop-shop for data protection. Instead of viewing features like VSS as one-stop data protection solutions, think of them as compliments to your backup strategy. Their limitations are the reason third-party Exchange backup tools exist. This particular feature is useful, but you need something more dependable for disaster recovery.

The real story: I agree that VSS by itself is not a comprehensive Exchange backup solution. Unless your skills with managing Microsoft Exchange border on superhuman, there is a need for third-party applications to step in and to provide more comprehensive features in an easy-to-understand or easy-to-use interface. Managing Exchange is a complex process and software vendors fill the gap by creating software to make managing Exchange easier. Whether you’re looking for a fast and reliable backup of your Exchange server or the ability to quickly recover an Exchange server to a hypervisor platform or new physical hardware, VSS along with a good third-party backup solution makes all the difference.

As you may know, StorageCraft ShadowProtect leverages VSS to take snapshots. This article explores how it all happens.


Photo Credit: Elliot Bennett via Flickr