Disaster Recovery for Hyper-V (Part 4)

If you would like to read the next parts of this article series please go to:


Although it is possible to create a Volume Shadowcopy Service backup of a Hyper-V server and all of its virtual machines, there are some major limitations that you need to be aware of. This article examines those limitations and discusses some workarounds.

In my previous article in this series, I explained that there are some major limitations to making host level backups in a Hyper-V environment. That being the case, I want to take the opportunity to talk about these limitations and some workarounds.

Dynamic Disks

Assuming that you are using the Volume Shadowcopy Service to create an online backup of the virtual machines on your host server, then the first limitation that you need to be aware of is that your virtual machines cannot contain dynamic disks. It is perfectly acceptable for the host operating system to use virtual disks, but you have to make sure that the guest operating systems treat all of their associated virtual hard drive files as basic disks.

The exact method of checking to see whether an operating system is using basic disks or dynamic disks varies a bit depending on the version of Windows that is being run. Generally speaking though, you should be able to open the Disk Management Console by entering the DISKMGMT.MSC command at the Run prompt within a guest operating system. I have included a screen capture of the Disk Management Console in Figure A for the benefit of anyone who may not be familiar with it. If you look at Disk 0, you can see that it is a dynamic disk. In some cases it is possible to right click on the disk (not on the volumes on the disk), and choose the Convert to Basic command from the shortcut menu.

Figure A: By looking at the Disk Management Console within a guest machine, you can tell whether the guest OS is configured to treat virtual hard drives as basic disks or as dynamic disks

A full blown discussion of the differences between basic and dynamic disks is beyond the scope of this article, but you do need to be aware that there are sometimes serious implications involved in converting a disk. Therefore, make sure that you have a thorough understanding of how the conversion process will impact the server before you attempt to convert a disk.

Restoring Virtual Machines

At the end of the previous article, I showed you how to modify the Windows registry so as to allow you to backup a Hyper-V server using Windows Server Backup. When you read about the technique, you may have wondered why Microsoft did not enable this capability by default. I do not have an official “Microsoft approved” answer to that question, but it could quite possibly be related to one very serious limitation.

If you perform a VSS backup using Windows Server Backup, you can not restore individual virtual machines. The restoration process (at least at the host level) is an all or nothing proposition. You can see a screen capture from Windows Server Backup’s Recovery Wizard. As you can see in the figure, we have the option of telling Windows Server Backup that we want to recover Hyper-V, but we can’t pick any individual virtual machines to restore. If I were to have continued with this restoration operation, all of my virtual machines would have been restored.

Figure B: Windows Server Backup does not allow you to recover individual virtual machines

Keep in mind that this limitation is Windows Server Backup specific. It may not necessarily apply to every VSS based backup application, but you definitely need to check your backup application to determine whether this limitation applies or not.

Another major limitation that you may encounter is that if a virtual machine contains multiple snapshots, then you would not have any trouble making a VSS backup, but you would not be able to restore the backup. Thankfully, there is a workaround to this issue.

The trick to successfully restoring the virtual machine is to manually recover the individual snapshots first. Once you have recovered the snapshots, then you can restore the virtual machine. The exact method that you will use for doing so varies considerably depending on the backup software that you are using. Here are the general steps that you would perform:

  1. If the virtual machine is running, turn it off and then delete the virtual machine

  2. Perform a file level restoration on the snapshot folders. By default, snapshots are stored in C:\Program Data\Microsoft\Windows\Hyper-V\Snapshots

  3. After you have recovered the individual snapshots, then perform an application recovery of Hyper-V. This will restore the virtual machines

A Saved State

One last limitation that you need to know about is that under certain conditions, virtual machines may be forced into a saved state while the VSS snapshot is taken.  There are three specific conditions that can cause this to occur.

First, a virtual machine will be forced into a saved state if the guest OS does not support VSS. This applies to older versions of Windows, such as Windows NT Server and Windows 2000 Server, as well as to non Windows operating systems.

The second condition that can cause a virtual machine to be forced into a saved state during the VSS snapshot is the Hyper-V integration services not being installed. Again, this mostly effects older versions of Windows and guest machines running non Windows operating systems, but it can apply to any guest operating system if the integration services have not been installed.

The third condition is that a guest machine will be forced into a saved state during the VSS snapshot process if the Backup (Volume Snapshot) component within the integration services has been disabled.

If you have not really done much with the integration services beyond installing them in a default configuration, then this concept might seem foreign to you. It is really pretty simple though. Although the integration services are usually installed as a single entity, it is actually made up of several individual services. If you want to see these individual services, right click on a virtual machine and choose the Settings command from the shortcut menu. When the Settings dialog box appears, select the Integration Services option. As you can see in Figure C, doing so will cause Windows to display the individual integration services.

Figure C: The integration services are actually made up of several different services

If you look at the figure above, you will notice that the last service on the list is the Backup (Volume Snapshot) service. This particular service must be enabled if you want to avoid putting the virtual machine into a saved state during the VSS snapshot process.


In this article, I have tried to explain many of the caveats associated with making a Volume Shadowcopy Service backup of Hyper-V and its guest machines. After reading about all of these issues, you may be wondering if creating this type of backup is even worth it. I am convinced however, that VSS backups for Hyper-V do have their place. In the next article in this series, I will explain what VSS backups are good for, and why these types of backups should only make up a portion of your overall backup strategy for virtual machines.

If you would like to read the next parts of this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top