I've said over and over that virtualisation significantly improves but also complicates the server backup process by increasing the options for backing up and restoring servers and data.
But when an admin backs up Hyper-V, these additional options don't have to add a layer of complexity.
Hyper-V VM backup error No. 1: Using backup agents in each VM
I like to think that there are different "perspectives" on Hyper-V backups:
- Backing up a VM from the host perspective: Grabbing a Hyper-V VM's Virtual Hard Disk (VHD) file for an entire machine restoration.
- A backup from the VM perspective: Transferring a VM's individual files and folders to tape using the traditional approach.
Installing a backup agent on each VM may seem like a convenient solution, but consider how this affects a system's resources. In the physical world, running a backup on a computer consumes a large amount of resources, but this usually isn't a problem because there are plenty to go around.
In the virtual world, on the other hand, you're often running multiple VMs on a Hyper-V host. The consolidation of VMs also means numerous instances of your backup software. Running any or all of these programs will dramatically affect the performance of other VMs.
Hyper-V VM backup error No. 2: Neglecting to configure Hyper-V for backups
Because of mistake No.1, many environments elect to back up VMs from the host perspective. While installing the Hyper-V role enables a server to host VMs, it does little to support this configuration. Therefore, you'll need to complete a few additional steps before backing up VMs from the host perspective:
- Ensure that Hyper-V Integration Services is installed on each VM and that the Backup Integration Service has not been disabled.
- Host-perspective backups require all VM disks to be NTFS-formatted basic disks. VMs that use dynamic disks or the File Allocation Table 32 file system prevent online backup, forcing a loss of VM service while the backup occurs.
- The Volume Shadow Copy Service (VSS) must also be enabled on all volumes used by a VM. Each volume must point to itself as the storage location for shadow copies, meaning that the shadow copy storage volume for the C drive must be the C drive.
Neglecting any of these configurations forces VMs to go offline during a Hyper-V backup, resulting in a loss of service during backup operations.
Hyper-V VM backup error No. 3: Not preparing properly for Windows XP and Windows 2000 Server
Online backup of VMs requires the support of Integration Services Hyper-V VSS Writer. This component, however, is not available for Windows XP or Windows Server 2000. Therefore, these older OSes cannot be backed up from the host perspective using online backups. Any OS backup requires a period of downtime to complete.
Hyper-V VM backup error No. 4: Forgetting about special disk configurations
Using attached VHDs with Hyper-V provides the greatest level of compatibility with backups. But this method has its limitations.
As such, many administrators use pass-through or iSCSI direct-attached disks to connect additional storage to VMs. An intrinsic problem with these methods is that the data will not be included in host-perspective backups. Essentially, if you install a backup client to a Hyper-V host and attempt to backup a VM's VHDs, that backup cannot traverse the VM OS to its internally connected disks.
To get around this problem, there are two backup options for such special disk configurations:
- A backup agent in the VM. A backup agent located in the VM allows it to see and back up direct-attached disks. This type of backup is not without its problems, however, as noted in mistake No. 1.
- Back up the disks from a storage area network (SAN) device perspective. The data on raw disks presented to VMs can be backed up by SAN-specific software. Consult your SAN manufacturer to determine whether your storage architecture supports this direct-from-SAN backup capability.
Hyper-V VM backup error No. 5: Not verifying support for Cluster Shared Volumes
With the release of Windows Server 2008 R2, Microsoft introduced Cluster Shared Volumes (CSV) to help back up Hyper-V. This feature allows a single volume to host multiple VMs -- in addition to enabling the cluster to fail over individual VMs instead of the entire cluster disk.
While this new capability is a boon for Hyper-V VM administration, it has limitations -- namely, that few backup vendors currently support this standard. The number of vendors supporting CSV has slowly increased, but verify that your provider supports it prior to enabling the feature on your Hyper-V cluster.
Hyper-V VM backup error No. 6: Believing that yesterday's backup methods fit today's
If the concept of "perspective" backups seems complicated, you're not alone. Virtualisation's effect on backups has changed how we should even think about backups.
The limitations and complexities of backups exist because of a traditional install-agent-and-grab-files method, which has been the standard for years. New technologies, however, take an entirely new approach, such as looking at individual block-level changes on a volume as opposed to taking a file-based method.
Microsoft's System Center Data Protection Manager, AppAssure Replay and other block-level backup products, for instance, take a fundamentally different approach to the backup problem, completely eliminating the complexities of "perspectives" and making restores of entire servers and individual files trivial for virtualisation professionals.
Greg Shields is an independent author, instructor, Microsoft MVP and IT consultant based in Denver. He is a co-founder of Concentrated Technology LLC and has nearly 15 years of experience in IT architecture and enterprise administration. Shields specialises in Microsoft administration, systems management and monitoring, and virtualisation. He is the author of several books, including Windows Server 2008: What's New/What's Changed, available from Sapien Press.
This was first published in February 2010