Organizations that need to protect Hyper-V environments generally have two options. The first option is to back up virtual machines (VMs) at the guest level. This process essentially involves installing a backup agent directly onto individual VMs, and then backing those VMs up as though they were physical servers.
The main advantage to using this approach is that it works well for backing up VMs that do not have the Hyper-V integration services installed. So long as a backup agent is available for the VM’s OS, the VM can be backed up.
However, there are some disadvantages to performing guest-level backups. For starters, the process does not scale very well. It can be tough to manage individual backups of large numbers of VMs.
On top of this, guest-level backups protect the VM contents, but not the VM itself. A guest-level backup is not aware of the virtualization stack. Therefore, the backup process protects the virtual hard disk’s contents, but virtualization specific components such as checkpoints and the VM’s hardware configuration are left unprotected.
The alternative to performing a guest-level backup is to back up Hyper-V at the host level. A host-level backup is aware of the virtualization stack, and backs up all of the VM components, including virtual hard disks and their contents. Host-level backups are usually the preferred backup technique, so long as the backup software is designed to work with the hypervisor and is aware of the OS and the applications running inside of the VMs.
A big part of protecting Hyper-V is determining the recovery point objective (RPO) and the recovery time objective (RTO) for your VMs. The RPO refers to the frequency with which recovery points are created. If for example, recovery points are generated every five minutes, then there is a potential to lose up to five minutes’ worth of data in the event of a failure. (For more on calculating your RPO/RTO read this blog.)
RTO refers to the length of time that it takes to recover from a disaster. In the not too distant past, RTO tended to measured in hours or in days. More recently however, many of the backup vendors have begun offering instant recovery capabilities for Hyper-V.
The creation of very frequent recovery points, which has come to be known as continuous data protection, demands the use of a disk-based backup target. The idea behind instant recovery is that if Hyper-V VMs are being backed up to a disk-based storage array, then it should be possible to mount and run a VM directly from the backup target. This eliminates the need for a long restoration process.
Of course, an organization would not want VMs running from a backup target on an indefinite basis. Likewise, there must be some mechanism in place to prevent the backup contents from being modified as they are used. The solution is typically to use Hyper-V checkpoints.
When a VM is mounted from a backup target, a checkpoint is typically created, so as to prevent the backup contents from being modified. Once the VM is running, all write operations are directed to a differencing disk. With the VM now running, the administrator can use the backup to perform a restoration in the background, while users continue to work from the backup copy of the VM. Once the restoration completes, the differencing disk contents are merged into the newly restored VM, and user traffic is seamlessly redirected back to the production VM.
Brien Posey is a 13 time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities and has served as a network engineer for the United States Department of Defense at Fort Knox. Posey has also worked as a network administrator for some of the largest insurance companies in America.
You can follow Brien on Twitter at @BrienPosey
Click here to find out how SolarWinds MSP can help you support VMs
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.