Live Backup of a Hyper-V Guest VM with Hyper-V VSS Writer

An earlier posting, “Backing Up Hyper-V Guests – Host-Based vs Guest-Based Methods”, discussed the differences between backing up virtual machines as though they were physical computers against utilizing software installed within Hyper-V’s parent partition to back up virtual machines as complete resources. When using the latter method, some backup software has the ability to coordinate with Hyper-v’s VSS writer to back up virtual machines without taking them offline. The considerations for enabling this to occur are examined in this article.

The Extra Challenges of Host-Based Backups

In the earliest Windows backup schemes, only files that weren’t in use could be backed up. As time went on, various technologies were developed to back up open files, some resulting in greater success than others. Finally, Microsoft introduced Volume Shadow Copy Service (VSS). This tool is designed specifically for backup and restore operations. It works with other processes to facilitate behind-the-scenes reading and writing of data. A proper understanding of VSS far exceeds the scope of this article, but it essentially coordinates a pause in I/O so that all protected data is in a consistent state at the moment that it is read. Virtual machines present a special challenge here. In a host-based system, the VSS writer (the tool is always called a writer, even if the operation is considered a “read”) in question lives at the parent partition level and the target virtual machine lives in an entirely different partition. Without some help, there is no way for it to coordinate the requisite pause with the virtual machine.

Hot Backup Requirements

In many cases, the challenge means that Hyper-V has to take a brute force approach to ensure that a virtual machine is in a state that is consistent enough for a VSS backup. Hyper-V places the VM in a saved state, triggers the VSS writer, and wakes the VM once the snapshot has been taken. This process is typically very fast, but it does not constitute a “live” or a “hot” backup. Hyper-V does have the ability to perform a backup of its guests without interrupting them, but there are several conditions that must be met.

• The latest Integration Services must be installed and the backup integration service must be offered. In the properties dialog of the VM, from either Hyper-V Manager or SCVMM, look on the Integration Services tab and ensure that “Backup (volume snapshot)” is checked (see screenshot below).
• The guest operating system must have its own VSS support (Vista desktops and later, 2003 Server and later).
• All of the virtual machine’s volumes must be formatted with NTFS. The volume that contains the .VHD(s) for the VM must also be formatted with NTFS. The guest operating system’s disks must be “Basic”, not “Dynamic” (this is not the same as dynamic vs. fixed VHDs, see screenshot below). These disks must each have 2 GB free space.
• The “COM+ Event System”, “Distributed Transaction Coordinator”, “Remote Procedure Call (RPC)”, “System Event Notification” and “Volume Shadow” services must be running within the VM. By default, these are set to “Automatic” and/or “Automatic (Delayed Start)”. The “COM+ System Application” and “Microsoft Software Shadow Copy Provider” services must at least be set to Manual, which is the default for these. It is acceptable, but not required, to set them to “Automatic” or “Automatic (Delayed Start)”.

The simplistic explanation of these backup types is that the VSS writer is called within the Hyper-V host. It notifies the Integration Services within the VM that a backup is about to occur. Integration Services negotiates with the VM’s VSS writer to take the VSS snapshot. With the exception of the Integration Services, all the above requirements are generally the same for a VSS-based traditional backup; the difference is that all components of the VM must comply. For instance, a traditional backup on a system with a dynamic disk or FAT32 volume can use the VSS writer for everything except the protected data that lives on a dynamic disk or FAT32 volume. Because the entire VM must be synchronized with the parent partition’s VSS writer, the entire VM must be able to interact with VSS or the entire VM must be paused while the parent’s VSS writer operates on it.

Cluster Shared Volumes

Cluster Shared Volumes (CSVs) are a great benefit to a Hyper-V deployment, but present a special challenge for backup. The purpose of CSVs is to allow multiple servers to access the same storage media simultaneously. To keep them from interfering with each other, CSV technology adds another layer of complexity that utilizes iSCSI persistent reservations. VSS technology is not designed to coordinate multiple hosts and their reservations, so all I/O must be handled by a single node for the duration of the VSS snapshot or there will be no guarantee that the data is consistent. To effect this, CSVs are placed in a special mode called “Redirected Access”, in which all nodes in the cluster make iSCSI requests through their designated CSV network so that only one node communicates with the volume. Backup software that runs from the parent partition must be specifically designed to set and release this mode or the quality of any backups it takes cannot be guaranteed and may not even complete. Note that software operating from within the VM is not affected. At this time, very few programs are CSV-aware, so you must take extra precautions that the software you use will satisfy this requirement. One of the leaders in this field is Altaro Software, who produce Altaro Backup for Hyper-V. It can communicate with clusters and back up VMs on CSVs, even if they are Live Migrated during a backup.