Why recursive VSS is good for backing up virtualized Windows Servers


This article can also be found in the Premium Editorial Download "Storage magazine: Everything you needed to know about object-based storage."

Download it now to read this article plus other related content.

VSS for VMs

That’s how it works with a physical server. The challenge is where those components are and how they interact when protecting virtualized machines with host-based backup. For that to work, two tiers of data conversations must occur: first between the backup server and the hypervisor (host), and then between the guest OSes and the host and/or backup server.

Microsoft’s Hyper-V hypervisor has its own VSS Writer for its “workload” of virtualized servers. The Hyper-V Integration Components (IC) that are automatically installed in each Windows guest OS include a VSS Requester.

So, with that in mind, let’s re-examine those eight steps:

From a host perspective:

1. and 2. The backup software’s agent runs on the Hyper-V host and recognizes Hyper-V as able to be protected because of the host’s VSS Writer.

3. The backup software makes a request to back up a particular VM.

4. The Hyper-V host’s VSS Writer does what it needs to do for its workload (a VM) to be backed up. Here, it gets the VM ready.

Here’s where it gets fun, because the way the host’s VSS Writer gets a virtual machine ready to be backed up is to tell the guest’s Hyper-V IC VSS Requester to be a backup agent, and the whole process happens inside the guest -- hence the term “recursive VSS.”

Inside the guest:

1., 2. and 3. The Hyper-V IC VSS Requester discovers VSS-capable workloads

Requires Free Membership to View

for protection, such as SQL Server or Exchange, via their VSS Writers, and then instructs those workloads to be backed up.

4. The guest-based applications do what they need to do to prepare for backups (flush logs, clear caches and so on).

5. After the workloads report being ready for backup, the workloads’ VSS Writers notify the guest Windows OS VSS Provider that the data is ready.

6. The Windows OS VSS Provider snapshots the data volumes as instructed by the workloads.

7. The Hyper-V IC VSS Requester then notifies its requesting backup server (which is actually just the Hyper-V host) that the VM is in a protectable state, including an application-consistent, software-based snapshot.

Now that the guest internals are protected, its container (the logical VM) is ready to be protected. Remember, in a host-based backup model, the VM as a whole is the workload to be backed up, so like any other VSS-based workload, once it’s ready, the original backup process continues.

Now the host process continues:

5. The Hyper-V host’s VSS Writer notifies the host VSS OS and its underlying VSS Providers that the VM is ready to be snapped.

6. The VSS Provider snaps the volume the VM’s virtual hard disk (VHD) resides on.

7. The host-based backup agent that requested the backup is given access to the snap and feeds the VHD to the backup server.

This was first published in June 2012

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: