Backup Central

What is Windows VSS & why you should care

Written by W. Curtis Preston Friday, 08 January 2010 01:43

I've just finished my research out what VMware and Hyper-V do (or don't do) with Windows Volume Shadow Services (VSS) on Windows Guests.  This whole thing started from a post by Scott Waterhouse that basically said that there was no way in VMware to get an application-consistent backup without performing a host-based backup. Scott appears to have been given at least some bad information, but he's a lot closer to the truth than most people realize.

But as I was googling my way around vmware.com, I found a number of people asking questions about just what VSS is, and other people giving incorrect answers to some of those questions.  So I thought that before I respond to Scott's post,  I should start with what VSS is and why you should care.
The simplest definition is that Microsoft VSS (Windows Volume Shadow Services) is a method to present a consistent image (referred to as a shadow copy or snapshot) of filesystem and application to a backup application so that it can be backed up.  But many people (including myself at one point) just think of this as the Microsoft equivalent of an open-file manager (e.g St. Bernard, for those who remember them).  While it is serving the same function, it provides so much more than just open file services.  For example, it can be used to do all of the following:

1. Perform completely supported backups of applications and communicate to those apps that they've been backed up, so that they can clear their transaction logs and perform other maintenance tasks.  In other words, instead of using a traditional Exchange backup agent, a backup app can tell Exchange to quiesce itself, then it can create a VSS snapshot, and then back up that snapshot as it would any other set of files in the filesystem.  Once it was done with that backup it could tell Exchange it had been backed up so that it can clear its transaction logs -- and this will be totally supported.  This is true for Exchange, SQL Server, Active Directory, SharePoint, and Oracle.
2. Perform regularly scheduled VSS snapshots completely independent of a backup application, allowing a user to recover old versions of his/her files using the "previous versions" tab in their file manager.
3. Provide a consistent image of several drives so that the backup application gets all files from backed up from a single point in time, even though it may take hours to actually perform the backup.

This is why VMware and Hyper-V's support VSS (or lack thereof) is so important.  A fully-functional VSS implementation would mean that customers could perform application-aware, transactionally-consistent backups of all virtual machines without peforming any guest-level backups of any kind.  What a beautiful thing.

Architecture

There are three parts to the VSS architecture: a requestor, a writer, and a provider.  A VSS requestor is the backup application that is requesting VSS to create a snapshot.  The VSS requestor in the case of VMware would be VCB or the vStorage API.  A VSS provider is an application or device that actually creates the snapshot.  Examples of these include Microsoft's built-in VSS provider for the filesystem and the snapshot capabilites built into many storage systems.  In the middle of these two sit one or more writers.  The job of the writers are to commnicate with the filesystems and/or applications that are being snapped, so that they may be quiesced and may be told that things were all successful or not -- so that they may do their appropriate housecleaning steps, such as clearing out transaction logs.  Examples of writers include the SQL Writer Service, the Exchange VSS Writers, the Sharepoint VSS Reference Writer, and the Oracle VSS Writer Service.  If you follow those links, you'll find that each of the writers has unique capabilities based on the needs of that particular application. To illustrate all of these parts, I've borrowed an image from Technet and put it below.





Here's how it works in a full VSS implementation:

1. The VSS requestor wants to create a snapshot, but first it must find out what kinds of writers are available.  To do this, it performs a referential VSS query.  The VSS core services responds with the writer(s) that is/are present on the Windows server being asked to create the snapshot.
2. The requestor then asks each of the writers to do their job -- however they do it -- to get the volumes where the applications reside ready to be snapped.
3. If the writers are all successful at doing what they needed to do, they communicate this to the requestor.
4. The requestor then tells the snapshot provider to actually create the snapshot.  Most often the provider will be the one that Windows has built into the operating system, but it can also be a storage system capable of making the snapshot.
5. If it's successful, it communicates this back to the requestor and tells it where it can get the data.
6. If the requestor is successful at backing up the data, it can again communicate to the writers that they can do what they need to do, such as clean out the transaction logs of their applications.

It's as simple as that.

What's this got to do with VMware & Hyper-V?

Hyper-V supports everything I've stated above for anything later than Windows 2003 and the last two or so versions of all the various applications.  This means you need no agents of any kind in Hyper-V VMs, even for applications.  You must admit, that's pretty nice.

Scott Waterhouse's original post  said that this simply wasn't possible in VMware -- that you had to run agents in VMware in order to back up applications.  I spent a good portion of this week trying to determine if this were the case.  (The short version is that he's a lot closer to the truth than most people realize.)  My complete findings are now in a later post, but I thought I'd post this one while I was finishing the other one.

< Prev		Next >