As organizations begin virtualizing their servers, the question of how to conduct a virtual machine backup can arise. Microsoft Hyper-V backups can be performed at the parent partition level, at the child partition level or both. Parent partition backups occur at the hypervisor level outside of the individual virtual machines. Child partition backups occur within the individual virtual machines.
There are pros and cons to each approach, and I recently wrote an article discussing the issue of whether it is better to back up your virtual machines at the parent partition or the child partition. However, that article didn't discuss application integrity considerations for Microsoft Hyper-V backups.
Application integrity is an issue because many of the applications that run on network servers depend on relational databases. Such databases tend to be large and frequently accessed, and a simple file copy backup usually will not work unless the database is first dismounted (which makes the database unavailable to the application). If you attempt a file copy backup of a database while it is online, then open files will likely be skipped. And even if all of the files are backed up, there’s a good chance the result will be corrupted because the database contents will change before the backup is complete.
The key to preventing that type of corruption is to use an application-aware backup product. For example, if you need to back up an Exchange Server database, then you would need an application that is compatible with Exchange Server’s unique requirements.
But things can get to be a little bit more complicated when you bring server virtualization into the picture.
Backups that are performed within a child partition are very similar to backups of standalone machines. An agent is installed on the virtual machine that you want to back up. As long as the backup software is aware of any applications that may be running on the virtual machine, then you should not have any problems with application integrity.
Backing up Hyper-V at the parent partition can be trickier. You need a VSS-based backup application that includes VSS writers for Hyper-V and for any programs that may be running within the virtual machines. However, limitations with Hyper-V or the backup software itself can result in corrupted application backups, even if the backup application is Hyper-V and application aware.
For example, with the proper registry key installed, Windows Server Backup is Hyper-V aware and fully supports VSS backups of Hyper-V and of various Microsoft applications. However, there are a number of limitations that can come into play.
VSS backups are designed to operate while the server or application that is being backed up remains online. For Windows Server Backup to perform a VSS backup of a virtual machine from the parent partition, the virtual machine must be running on a current Microsoft operating system. Older operating systems such as Windows 2000 and Windows XP are not VSS aware. Likewise non-Microsoft operating systems do not work with VSS backups.
Another requirement is that the virtual machines that are being backed up must be running the Hyper-V Integration Services. Without the Integration Services (which cannot be installed on older operating systems or non-Microsoft operating systems) VSS backups are not possible.
Even if the virtual machine that is being backed up is running a modern Windows operating system and the Hyper-V integration services, it may still be considered non-VSS compliant (from the standpoint of Windows Server Backup) if the virtual machine is using dynamic disks.
If you attempt to back up a Hyper-V server from the parent partition and one or more of the virtual machines running on that server does not fulfill all of the requirements for a VSS backup, Windows Server Backup will force non-compliant virtual machines into a saved state, run the back up process, reboot the virtual machine and restore the saved state.
This can be a big problem for application servers. A saved state freezes the virtual machine’s virtual hard disks and captures the contents of its memory. However, the virtual server remains unavailable until the saved state is restored, which means that database transactions that were in progress at the time of the backup may fail. In fact, the documentation for some database applications specifically states that virtual machines running the application should not be placed into a saved state.
The restrictions around performing VSS backups of virtual machines may make it seem as if all backups should be created within the individual virtual machines.
However, it is perfectly acceptable to create parent partition backups if the individual virtual machines meet the VSS backup requirements and the backup application can detect Hyper-V and other applications.