Microsoft’s Hyper-V Team Blog this week adds some useful information about the requirements needed if you want to back up your Hyper-V-hosted VHDs without powering them down.

Hyper-V relies on the Volume Shadow Copy Service (VSS) to leverage the quiescing of virtual machines during their backup.  This ensures that the file system remains consistent during the period of the backup and the machine returns from a restore without corruption.  This VSS integration is excellent, because VSS writers can work with VSS-aware applications like SQL, AD, and Exchange to ensure applications return in a consistent state as well.  VMware currently has limited support for VSS integration in their Server 2.0 release (currently in RC2) as well as ESX’s VCB in v3.5 U2.  Hyper-V being a Microsoft product, this out-of-the-gate integration is in this blogger’s opinion a great value-add.

In order to do online backups, however, you do need a few prerequisites.  From the blog post:

• Integration services are installed and the backup integration service has not been disabled.
• All disks being used by the virtual machine are configured within the guest operating system as NTFS-formatted basic disks. Virtual machines that use dynamic disks or the FAT32 file system prevent an online backup from being performed.
• Volume Shadow Copy Service must be enabled on all volumes used by the virtual machine with a specific configuration. Each volume must itself as the storage location for its shadow copies and that mapping must be available to the Hyper-V VSS writer. In other words, the shadow copy storage of C: should be on C:, the shadow copy storage of D: should be on D:, so on an so forth.
• If an online backup cannot be performed, then an offline backup is taken. This type of backup results in some degree of downtime. A variety of factors can affect the time required to take an offline backup. If the virtual machine is running or paused, it is put into a saved state as part of the offline backup process. After the backup is completed, the virtual machine is returned to its existing state.

The post also discusses a few gotchas you should be aware of if you’re using some of the more interesting storage arrangements:

• Physical disks that are directly attached to a virtual machine (sometimes referred to as ‘pass-through disks’) cannot be backed up by the Hyper-V VSS writer. As a result, this type of disk will not be included in any backup performed by a backup program that uses the Hyper-V VSS writer. In this situation, you would need to use some other process to back up the physical disk. For example, you could run a backup of the data on the iSCSI storage from a backup application running in the guest operating system.
• Storage accessed from a virtual machine by using an Internet SCSI (iSCSI) initiator within the guest operating system will not be included in a backup of the physical computer. In this scenario, you must use another process to back up the data from the iSCSI-based storage before you perform a full server backup. For example, you could run a backup of the data on the iSCSI storage from a backup application running in the guest operating system.
• iSCSI-based storage is supported for backup by the Hyper-V VSS writer when the storage is connected through the parent partition and the storage is used for virtual hard disks.

The second and third bullet points are critical here.  If you’re using iSCSI for storage its fairly likely that you’ll at some point want to begin adding iSCSI-based LUNs into your VMs themselves.  The way I read this is that today this isn’t a good idea unless you want to manage two separate backup mechanisms, namely an image-level backup for the VHD file itself and a separate in-VM backup for the files stored on the in-VM iSCSI LUN.