Microsoft Hyper-V backup strategy and best practices

In this podcast we outline how to approach a Hyper-V backup strategy and highlight a few best practices that could mean the difference between success and failure in Hyper-V backup.

While Microsoft’s Hyper-V has a much smaller share of the market than VMware’s virtual server product, the two share lots of similarities when it comes to backup. But there are also some peculiarities about Hyper-V backup that you need to get right to achieve consistently successful backups.

In this podcast, Assistant Site Editor Fran Sales interviews Bureau Chief Antony Adshead about Hyper-V backup strategy and best practices for backup in that environment.

Play now:
Download for later:

Microsoft Hyper-V backup basics and best practices

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As

Sales: What are the basics of a Hyper-V backup strategy?

Adshead: Let's start off with the basic facts of virtual server backup, and here we come up against the laws of physics. Namely, if you start backing up numerous virtual servers in one physical box, you’re going to ramp up I/O demands to very high levels.

For that reason, many people choose to back up at the Hyper-V host level rather than backing up individual virtual servers. It might have made sense in a physical server environment to back up with one agent per server, but it’s a crude way of approaching virtual server backup.

The Hyper-V host, which aggregates a number of virtual machines, is an obvious place to consider backing up. The difficulty is that many virtual machines being managed by the hypervisor are going to be active simultaneously so you need a way to stop them while you carry out the backup.

To do this, Microsoft has an in-built schema called Volume Shadow Copy Services (VSS). This stops the virtual machine temporarily while a snapshot of its state is taken. This stopping is known as quiescing, or quiescence.  

VSS as a schema has three components: a requester, a provider and a writer. The requester is the application that requests the snapshot, namely, the backup app for our purposes here. The provider is the thing that effects the writing of the snapshot, which in a smaller implementation would be the Windows OS but in a larger environment would be the storage array. The writer is part of the application that is being quiesced when it’s time to take the snapshot. It could be an individual application like SQL Server or would be the Hyper-V host itself in a host backup scenario.

VSS is a crucial element of Hyper-V backup, so when looking for a backup app for such an environment make sure it works with VSS.

Another desirable feature in Hyper-V backup is the ability to do incremental-forever backups. The reason for this goes back to the physics of the whole thing. Full backups just aren’t an attractive option in an environment where there are multiple virtual servers in one physical box. 

Sales: What are the main things you need to get right in Hyper-V backup?

Adshead: We’ve talked about some of the basics of Hyper-V backup, but obviously it’s nowhere near the whole picture. There are a few key things to get right to avoid problems. And you might even want to consider backing up at the VM level, despite what I’ve said here already about backing up at the host.

First off, though, a few things to watch out for when backing up in Hyper-V.

VSS needs disk space to work: a minimum of 300 GB on each virtual hard disk (VHD). This is used to write the quiesced data to and it’s from where the backup app copies it. Without that space, the backup will fail.

Hyper-V also has a number of integration components that handle timekeeping, quiescence, data exchange between guest and host, etc, and these need to be correct on all your VMs or backups will fail or be inconsistent. Being up to date with Microsoft patches goes a long way to making sure integration component issues don’t arise.

Now, let’s go back to the issue of whether to back up at the host or individual VM level. While there are a lot of good reasons to back up at Hyper-V host level – namely, server resource efficiency and possibly licence costs -- there can be circumstances where you want to back up at the VM level. Just as a side note here, in Hyper-V, the almost-equivalent terms to host and VM are parent and child partition.

So, for example, in cases where restoring an entire hypervisor would prove too cumbersome, you might want to consider backing up only the child partition. Of course, you want to avoid the potential resource bottleneck issue, so you could, for example, choose to back up the entire hypervisor but also back up some key VMs that often need restores. Note that if you do opt to back up child partitions, you’ll need to re-create the VM before restoring data as the child partition doesn’t back up the VM’s settings.

Finally, a word about selecting a backup provider for Hyper-V: Apart from VSS compatibility and ability to do incremental-forever backups, you should also ask about granularity of restores. When using, for example, Windows Server Backup in Server 2008, you can only restore entire volumes -- ie, full hosts -- and not individual VMs. That’s also going to be the case with some third-party backup products too. Also, if you’re going to want restoration of individual files within a VM, check [that] this is possible when evaluating backup products as [this capability isn’t] universally available.

Read more on Data protection, backup and archiving