In the last few posts I showed you a simple (and low cost) manual method for back and recovery of virtual machines running on Hyper-V. When I ran through the process in my lab, I purposely used two different types of virtual machines:
I mentioned in the VSS Overview post that contemporary versions of Windows running in a VM on Hyper-V that support VSS and have the appropriate Integration Services installed can coordinate VSS activities with many of the applications and services inside the VM when a backup request is made on the physical host. This coordinated VSS processing via the Hyper-V Integration Services means that VSS aware applications can be backed up in a VM with absolutely no downtime. without installing an additional backup agent inside the VM (saving cost and reducing complexity).
For that other class of VMs, those that do not support VSS or do not have the “Backup” Integration Service enabled, Windows Server 2008 R2 and Hyper-V still can create a consistent backup, but the process is a little bit different. If the VM (for whatever reason) cannot itself consume the coordinate VSS request, Hyper-V will save the state of the VM (hibernate it) copying the contents of memory to disk and then generate a snapshot of the disk housing the VM. Here’s how the process looks to a running VM in this category:
Remember I did this entire process simply by requesting a backup of the physical Hyper-V host – I didn’t need to request all of this to happen Windows Server 2008 R2 / Hyper-V / VSS did it all for me! Any VSS aware backup of Windows Server 2008 should be able to do the same thing for you, if you use diskshadow, Windows Server Backup (WSB – part of Windows Server 2008), or a more full featured enterprise backup solution.
The key thing to note is that you can improve the backup and recovery of even unsupported operating systems running on Hyper-V.