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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

DriveHQ has offered Cloud Backup and Cloud IT service for over 10 years. Backing up virtual machines can be extremely challenging. To help our customers solve the problem, published a very detailed technical documentation about the best practices to backup virtual machines. Please visit the DriveHQ support page:

Using DriveHQ's online backup solution to backup virtual machines, you can achieve:

(1) Minimize the amount of data to be backed up;
(2) Faster to restore;
(3) Lower cost;
(4) Be able to restore individual files and folders;
(5) Minimize the chance of data corruption and the impact of data corruption.
(6) More flexible. You can restore VMs on to different physical servers.


Easiest way is to use something like Altaro's hyper-v backup tool - Really doesn't cost much, has everything I need and just works


"VSS needs disk space to work: a minimum of 300 GB on each virtual hard disk (VHD)." Source please? This sounds ridiculous. I don't have an extra 300GB per VHD and my backups are working fine. 300MB maybe?


The statement that 300GB are required by VSS is not entire accurate. We at recommend the following for Hyper-V backups: use vssuirun.exe and set the VSS storage area limit to unbounded or to about 10% of the entire VHDX load you're backing up at a time. Since BackupChain backs up each VM in isolation (unless you use the simultaneous option), VSS has to buffer only the altered blocks inside that particular VM for the length of the backup. The fast you back up, the less buffer space is needed for VSS. Conversely, VSS storage area needs to be increased when backups run slower, for example, when a speed limit is being used.
The 300GB recommendation above would definitely be enough for a simultaneous backup load of about 1 to 2TB, depending on the write activity inside VMs.