The Windows Volume Shadow Copy Service (VSS) can improve a virtual machine backup strategy by ensuring consistency in data copied from virtual machines (VMs) at specific points in time.
But for a successful
To further complicate the situation, different hypervisors and backup approaches require vastly different architectures. So now let’s look at how virtual machine backup strategy differs on the Microsoft Hyper-V and VMware vSphere platforms.
Coordinating Hyper-V virtual machine backup
Virtual machine backup is arguably one of Hyper-V’s strong points. Having the same operating system at the host and guest levels -- as Hyper-V does with Windows -- can uniquely benefit a VM backup strategy. In this architecture, Windows VSS is natively installed to the host and each VM, which facilitates host-level backups. The host also has the Windows Server Backup application, which can serve as a VSS requestor. You can even install third-party products to support your virtual machine backup strategy.
Backing up a Hyper-V virtual machine requires coordination between the Windows VSS instances on the host and the guest. To do so, the Hyper-V Integration Components installs code to every VM. This code allows the Windows VSS writer on the host to communicate with any registered VSS Writers inside running VMs to coordinate quiescence activities. This stacking of VSS instances ensures that applications successfully quiesce as virtual hard disk (VHD) files are backed up.
Using Windows VSS for VMware VM backup
VMware vSphere doesn’t use the same architecture as that in Hyper-V, which means that Windows VSS components aren’t part of its management partition. With no Windows VSS at the host level, the snapshot and quiescence activities must be controlled through some other service. For VMware virtual machine backup, you can use VMware Consolidated Backup or its successor, vStorage APIs. The vSphere Data Recovery feature is another option.
As with Hyper-V’s Integration Components, vSphere VMs require a specific installation to add the VSS Requestor components. This installation is part of VMware Tools.
There is an issue with VMware’s VSS Requestor implementation that merits additional attention: Any VM that was originally created in vSphere 4.0 requires an extra set of configurations to support application-consistent quiescence. Page 38 of the VMware Data Recovery Administration Guide (in PDF format) discusses the 11 required steps of this process. The process involves enabling the disk UUID attribute disk.enableUUID in a VM’s configuration parameters. VMs that were initially created in vSphere 4.1 do not require this additional configuration.
If you don’t complete these extra steps for a successful VM backup strategy, your VMs may restore with inconsistent application data. Like the lengthy database verification process that results after accidentally yanking the power cable from an Exchange server, restoring inconsistent data isn’t a desirable situation.
Third-party tools for a VM backup strategy
Numerous third-party tools integrate with Hyper-V and vSphere for virtual machine backup and restore. Some take the orchestration process a step further by automatically inserting agents into VMs as they are backed up.
The agent-assisted approach improves the Hyper-V restore process by ensuring that an intelligent agent is present as the VM file makes its way to the backup server. By incorporating agents into a VM backup strategy, you facilitate better VM restores.
This agent can facilitate the recovery process by ensuring that an Active Directory Domain Controller always restarts in nonauthoritative mode, for example, or by dismounting Microsoft Exchange mailbox stores as an Exchange Server is powered on. For a successful restore, extra steps like these are required, but they cannot occur if the agent is not present when the VM is powered on.
Orchestrating virtual machine backup with Windows VSS and the host isn’t always as simple as it may seem. Particularly for mission-critical applications, many components of a VM backup strategy must integrate if your VM is to restore correctly.
This was first published in February 2011