There are two basic approaches to protecting virtual machines running Windows--at the guest level and at the host level.
The guest level backup approach treats a virtual machine the same as a physical machine, and runs backups within the virtual machine, using any of the same options available to physical machines, from a legacy backup approach to newer technologies that may include taking internal snapshots, using deduplication techniques, and moving data across the network to a backup storage device. The host level backup approach relies on the virtualization software that hosts the virtual machines to protect the VM virtual disks and configuration files, often in conjunction with third party applications.
A virtual machine may be a file server that just runs with virtual disks (VHD or VMDK files), or it may attach to physical disks, as well, for storage. A common example would be a virtual machine attached to a SAN volume using an iSCSI initiator. It may be running an application such as Exchange or SQL, again, either with virtual disks alone or by attaching to physical disks. A proper backup of a virtual machine running Windows requires that both virtual and physical disk volumes and applications be quiesced and in a consistent state when the snapshot is taken, and this ultimately requires a consideration of the disks used by the VM and the backup application's communication with VSS writers working within the VM to quiesce a volume or application.
In Windows Server 2003 and later, built-in Microsoft Volume Shadowcopy Service (VSS) snapshot technology exists to quiesce a volume or application such as Exchange or SQL so transactions are registered prior to the snapshot. A backup solution that integrates with this technology is consistent, safe and proven, and also Microsoft best practice. In fact, with Exchange 2010, Microsoft’s only approved backup method is through the Exchange writer for VSS. When you run a guest level protection plan within a virtual machine, such as with dataStor’s SQL or Exchange protection plan, you create an application-consistent and application-aware backup, creating snapshots on all required virtual and physical disks.
Again, if the VM attaches to physical disk, the backup must be able to take a snapshot of the physical disk to protect the files stored on that disk, and host level backups cannot do it. The issue is whether a host level snapshot provider will be aware of the physical disk and can reach all the way out to it to create a snapshot on it. Hyper-V, for example, does not support host level backups of physical disks attached to virtual machines, so data on the physical disk will not be protected with a host level backup. Microsoft best practice in this case is to run guest-level backups with periodic host level backups. See Microsoft’s Planning for Backup, updated March 17, 2010 as of this writing, for more information. In addition, VMware has issues with Raw Device Mapping in physical mode, common with clustered environments. This means that even if a host level backup application can create an application consistent backup on virtual disk, (at least, usually), it is a moot point when the virtual machine connects to physical disk via Raw Device Mapping (RDM) in physical mode. You must find another method of protecting those volumes, which brings us back to guest level backups.
Next post, we'll go into a little more detail on host level backup limitations.