Article: Volume Shadow Looms Large

I just found out this new article about VSS in the Microsoft Certified Professional Magazine, containing several interesting comments about VSS usage. Ron Rynbrandt, (who works for the Dr Pepper 7UP Bottling Group) had the following observation:

We use VSS for shared folders, and we love it. I store all of my Citrix user folders and profiles on a server where I use VSS as a restoration tool. It replaces about 95 percent of all restores we perform, and reduces restoration times from 2-3 hours (from tape) to about five minutes. We do restrict usage of VSS restores to just IT people as part of our change control process.

One small caveat: When I first set up VSS, I let it use unlimited space on the drive. This worked okay for a while, until the drive got close to full. Then, when the VSS service ran again, it ran out of disk space and corrupted all VSS images on the drive. This happened a couple times before I set a limit on VSS space to 5 MB less than the capacity of the drive. Now, VSS images are handled in a FIFO order correctly.

And also a similar comment later in the article from Falco Dam, (who works for IT-to-IT, a training and consultancy company in The Netherlands):

You always run the (albeit minimal) risk of overwhelming the Volume Shadow Copy Service, which causes all of your shadow copies to be deleted. This risk can be mitigated by placing the VSC data on a separate spindle of disks, making sure you have enough resources, and installing SP1 which includes KB 833167 as you've pointed out. Still, you need to be aware of this risk.

Correct. I would add: You are not likely to hit this issue except on a very high write I/O on large scale deployments. This is a known problem that was addressed for Windows Server 2003 RTM in KB 887827 (which includes both KB 826936 and KB 833167 hotfixes). Also, this fix is already addressed in Windows Server 2003 SP1.

Anyway, please note that, unless you already deployed SP1, the latest VSS hotfix for RTM is now KB 887827 and this includes all changes in all previous VSS hotfixes for Windows Server 2003 RTM (non-SP1), like 833167.

Another set of comments from Falco Dam:

How many shadow copies you can go back, therefore, depends on the activity on the volume. I've found it quite difficult to predict up front the number of saved shadow copies you will have available at any one time; you only know when you've implemented it.

True - it is difficult to estimate the space needed for VSS, that it depends on the particular I/O pattern that you have on your volume. The most accurate way to estimate this is to let it run for a while, and then see how much space you have for all shadow copies.

Also, as a very general heuristic, you might consider the following rule: the used size of the a certain shadow copy is roughly equal with the amount of changed data since the previous shadow copy. However, I would stress out that this rule might return sometimes a slightly different number than in practice. Just to present a particular exception, "eating" existing free space on the volume is not generally considered "changing data" unless this free space comes from a deleted file that was present at the time of previous shadow copy, etc.

Any backups you make (using NTBackup or any other tool) will only back up the current data. There is no way that the shadow copies themselves can be backed up (none that I know of, anyway). You may want to consider redundancy in the spindle that you use to hold the VSC data.

Unfortunately, this is by design, and you have to rely on a real backup solution to guarantee that your previous "versions" are correctly archived. The upcoming Data Protection Manager will address a very similar scenario.

As for the Previous Versions client, I am always wary to just install it on any workstation. I'd hate to see some clueless user playing with it and restoring a massive folder from a shadow copy with a single click. There's just no way to undo this damage. My advice is to install the Previous Versions client on administrators' computers only and perhaps some power users.

Good point. We had lots of customer requests for this feature, and this issue is now addressed by the new KB 888603 hotfix, that allows you to selectively disable either the "Restore" button, or disable the whole "Previous Versions" tab. This setting is controlled through a registry key. Note that you might define a custom Group Policy which changes this registry key therefore allowing certain classes of machines to access and/or perform restore through the Previous Versions tab.

And, in the Comments section, an observation from Simon Lucas:

Is it true that VSS copies files whose only changed attribute is their position on the disk? This is relevant to Defrag or Diskeeper where only the position is changed and can result in large volumes of data being stored by VSS during the initial stages of defragmenting when fragmentation was severe.

This is somewhat true - but it will also preserve changed files (as mentioned above).  In order to avoid the Defrag problem, you need to format your volumes with 16KB cluster size or more. More details about this are presented in KB 312067.

P.S. Also, you might want to check out the previous article from Bill Boswell on VSS here.

[update - various minor fixes done]