A review of BackupAssist within a Hyper-V Environment

By Brien Posey

Introduction

Although server virtualization has revolutionized the IT industry, one of its side effects has been that disaster recovery is far more complex than when using only physical servers. Some of the reasons for this relate to the way that Microsoft's Hyper-V is designed, while other complications stem from the limitations of backup applications.

Traditionally, there have been two options for backing up a server that's running Hyper-V. The first involves creating a backup of the host server. A host level backup will back up the host operating system and all of the virtual machines hosted on the server. This backup will include the configuration data for each virtual machine as well as all of the individual virtual hard drive files and virtual machine snapshots.

Although this type of backup sounds promising, it has major limitations. In particular, organizations wishing to perform a host level backup must first determine whether they can perform online backups or offline backups. Although online backups can be made while virtual machines are running, numerous conditions must be met. While offline backups eliminate most of these conditions, they require virtual machines to be shut down before the backup of the host starts. The table below outlines the advantages () and disadvantages () of each type.

As you can see, numerous conditions must be met to run online backups at the host level. Offline backups do not have these requirements, but virtual machines must be stopped prior to running the backup, which can be a major problem for organizations that require their servers to be available 24 hours a day.

Even if you are able to meet the criteria for performing an online host level backup, the backups are not perfect. Windows does not include virtual networks in the backup, so you will have to manually create any virtual networks and reattach each virtual machine should you ever have to perform a bare metal restoration of a Hyper-V server. A more significant limitation, however, is that depending on what backup software you are using, you may have little control when restoring virtual machines. For example, Windows Server Backup restores data at the volume level, and does not allow you to restore individual virtual machines. Third party backup solutions may be able to restore individual virtual machines, but typically cannot use a host level backup to perform granular restorations of those virtual machines.

The second option for backing up Hyper-V is to run guest level backups. A guest level backup runs at the virtual machine level rather than at the host operating system level. A guest level backup will provide for granular restoration of a virtual machine, but also has some major limitations, which are explained below:

With the above challenges in mind, I wanted to assess whether BackupAssist was a suitable product for a small to medium business looking for a straightforward solution to the difficulties inherent in any Hyper-V backup and restore strategy.

An Introduction to BackupAssist

BackupAssist v6 is an affordable backup application designed for small and medium sized businesses. Although BackupAssist has many features, I was particularly interested in the claims that it could simplify disaster recovery in a Hyper-V environment.

Prior to the release of BackupAssist 6.0, I had always recommended that my clients who use Hyper-V perform regular backups at both the host level and at the guest level. This approach provides comprehensive protection and does not require any extra investment in software, but it is time consuming and inefficient because every server has to be backed up twice. When I read that BackupAssist claimed to be able to create a one-pass backup of a Hyper-V host that allowed for recovery at all levels, I knew I had to take it for a test drive.

Figure A - The difference between a one pass and a two pass backup of Hyper-V.

Testing Methodologies

For my initial testing, I installed Windows Server 2008 R2 on a server and created three virtual machines. The table below lists the virtual machines hosted on the test server:

Table A - Virtual machine configuration on the Hyper-V test server.

I installed BackupAssist v6.0 directly on the host server, but did not install any backup software on the virtual machines. I attached a two terabyte external hard drive to the host via a USB cable to use as the backup media.

Figure B - Testing setup used.

Once the testing infrastructure was in place, I performed the following tests using BackupAssist.

Test 1: Restore a Virtual Machine's Configuration

The first test was to see if BackupAssist would allow me to restore a virtual machine's configuration without forcing me to restore the underlying virtual hard drive file (.VHD file). The reason for performing this test is that it is easy to accidentally delete a virtual machine when working within the Hyper-V Manager. When a virtual machine is deleted in this way, the .VHD file remains intact, which means that a full restoration would return the entire virtual machine to a previous state, which would not be desirable since the most current data is saved in the .VHD file.

I began by creating a VSS-based Windows Image backup of the entire host server, including all of the VMs residing on it. After the backup completed, I logged in to virtual machine VM1 and changed the background color of the Windows desktop. If the desktop retained its new background color after completing the test, it would prove that the VHD file had not been overwritten.

After modifying the Windows desktop color, I shut down virtual machine VM1, and then deleted it from within the Hyper-V Manager. I then used the BackupAssist Restore Console to restore VM1. After clicking the Restore To button, I configured the restore options so that existing files would not be overwritten.

The restoration worked without any issues, and the virtual machine retained its new desktop color. The virtual machine's configuration was restored, but the virtual hard drive file remained unchanged. I was successful in restoring a virtual machine's configuration without overwriting the corresponding virtual hard drive file.

Test 2: Restore a Single Virtual Machine and its Virtual Hard Drive File

For my second test, I wanted to see how well BackupAssist worked when restoring a virtual machine after the associated virtual hard drive file (.VHD file) had been deleted. For this test, I deleted virtual machine VM3 from within the Hyper-V Manager, and then deleted the corresponding VHD file.

I opened the BackupAssist Restore Console and selected the virtual machine that I wanted to restore from within the Microsoft Hyper-V VSS node. I did not attempt to select the virtual machine's VHD file for restoration because I wanted to see what would happen if I selected the listing for the virtual machine itself.

When the restoration completed, I verified that the virtual machine's VHD file and all of the corresponding support files had been restored, even though I had not explicitly selected them for restoration. This proved that BackupAssist is able to restore an entire virtual machine without requiring the administrator to manually select each individual sub-component for restoration.

When the restoration completed, the virtual machine was listed within the Hyper-V Manager, but was turned off. I turned the virtual machine on and it booted successfully. I was able to log in to the newly recovered server and verify that all of the system services were running.

Test 3: Granular Restore

One of BackupAssist's most unique features is that it allows you to perform granular restores without having to perform a guest level backup from within an individual virtual machine. I wanted to test BackupAssist's granular restoration capabilities to see how well they work.

BackupAssist is designed so that you can perform a granular restoration of any Hyper-V backup. This means that it is possible to restore individual items from within a virtual machine, even if you didn't create a guest level backup. You don't have to do anything special to your backup job to enable granular restoration, but the actual restoration process requires the use of the BackupAssist VM Granular Restore Add-on, which is not included with the base BackupAssist license.

Once the BackupAssist VM Granular Restore Add-on has been enabled, performing granular restorations is a breeze. BackupAssist scans the backup media and shows you which backups are present, and which virtual machines are included in each backup. Once you select the backup from which you want to restore, you need to specify which virtual machine you need to restore data to and which of the virtual hard drives associated with that virtual machine contains the data. After making your selection, you may see another screen asking you to select the partition on the virtual hard drive that you have chosen which contains your data.

At this point, BackupAssist allows you to mount the virtual hard drive, from the backup, as a drive letter on the host server. Once mounted, you are free to browse the virtual hard drive's contents, as shown below in Figure C. The software also provides you with the ability to export guest volumes as separate .VHD files, which is useful should you want to rebuild a virtual machine in the event of a major disaster scenario.

Figure C - BackupAssist mounts backed up virtual hard drive and assigns it a drive letter in Windows.

One issue that I did have with this approach is that because the virtual hard drive is mapped to a drive letter on the host server, it is not directly accessible from the virtual machine to which you are attempting to restore the data. However, you do have a few options for restoring the data to the virtual machine, such burning the files to a DVD or sharing a folder to the network. Either of these methods can be used to transfer restored data to the individual virtual machine where it belongs.

Test 4: Restore Individual Virtual Machines to Another Server

Next, I wanted to find out if I could back up a collection of virtual machines and restore them to a different Hyper-V server running on dissimilar hardware. On my first attempt, the restoration server recognized the backup, but the restoration failed because the underlying hardware was too different. My original server had a second drive that was dedicated to storing the virtual machine's VHD files. This second drive did not exist on the restoration server, so the restore operation failed (as I would have expected).

Figure D - Restoration to dissimilar hardware.

For my second attempt, I removed and recreated the virtual machines listed in the Table A on page 4, but this time I located the corresponding virtual hard drive files within a non-default location [1] on C: drive. I backed up the server, and then attempted to restore my virtual machines to the secondary server, as shown in Figure C below.

Figure E - BackupAssist allows you to restore virtual machines to a different host server.

When I attempted the restoration, I learned that the external hard drive containing the backup had to be mapped to the same drive letter on both machines. For example, when I originally created my backup, Windows had assigned the external hard drive to F: drive. However, when I moved the drive to the second server, Windows mapped drive letter J: to the external hard drive. I had to remap the system's drive letters so that the external hard drive became F: drive. Once the drive mappings had been corrected, the restoration worked perfectly.

It is worth noting that BackupAssist provides a tool called the Hyper-V Config Reporter, which is used to create a HTML report of your Hyper-V Host and Guest Virtual Machine settings, making it easy to recreate an existing VM on a new Host. By using this tool, it is easy to avoid the situation that I just described.

Figure F - The Hyper-V Config Reporter documents Hyper-V host and guest settings

One last thing I want to mention about this particular test is that even though the server to which the virtual machines were restored had a network adapter that was identical to the one used in the server on which the backup was made, the virtual network settings had to be reconfigured after the restoration completed. This was due to a Hyper-V limitation, and had nothing to do with BackupAssist's capabilities.

Test 5: Bare Metal Restore

The last test that I attempted was a full bare metal restore of the host server and everything on it. For this test, I created a Windows Imaging based backup job and configured BackupAssist to back up all local hard drives (excluding the external drive that was being used as backup media), the system state, and Microsoft Hyper-V.

When the backup completed, I removed the server's hard drive and replaced it with an empty hard drive. I booted the server from the Windows Server 2008 R2 installation DVD, and chose the option to restore the computer from a system image. Initially, Windows refused to recognize the system image that had been created by BackupAssist. After verifying that Windows was able to read from my external hard drive I contacted the BackupAssist technical support department. The technical support staff member was very helpful and told me that I should not select the option to back up Microsoft Hyper-V. If you select a VSS application for backup, such as Microsoft Hyper-V, this affects the types of recovery you can perform from an image backup created with Windows Server Backup. Notably, it will remove the option for 'Bare Metal Recovery' for your image backup. This is why I was unable to perform a bare metal restore from my initial image backup.

Following the advice that I had been given, I recreated the backup job, but this time did not select the Microsoft Hyper-V VSS option when choosing the objects I wanted to back up.

This would ensure that the 'Bare Metal Recovery' option would be enabled in my image backup. You can verify this by running wbadmin get versions from a command prompt and checking the 'Can recover' section.

When I attempted the restoration this time, Windows had no trouble recognizing my image backup.

When the restoration completed, I was curious to check the state of my Exchange Server. I had intentionally neglected to configure BackupAssist to perform an Exchange Server specific backup when I created my backup job. Normally, this would violate Microsoft's recommended best practices because database corruption can occur if you do not back up Exchange Server properly, especially if there are multiple Exchange Servers on the network. In this case I was dealing with a single Exchange Server in a lab environment, so I was interested to see what would happen after performing a bare metal restore. Exchange Server is a complex application that is easy to break, so I wanted to see whether all of the various system services would start after the restoration.

The end result was that my host server and all of the virtual machines were restored perfectly. When I checked the Exchange Server, all of the Exchange related services were running, and the mailbox database had been mounted, which proved that the database had remained in a consistent state.

Test 6: Using Hyper-V failover clusters

After testing BackupAssist against standalone Hyper-V servers, I decided to see how it would perform when run on a Hyper-V server that was a part of a failover cluster. For these tests, I created a two node cluster running on Windows Server 2008 R2. A third server running Windows Storage Server 2008 hosted a volume that was used as shared storage by the cluster nodes. The individual cluster nodes communicated with the shared storage using iSCSI over a dedicated network segment. The Windows Storage Server also acted as a file share witness for the cluster since there were only two cluster nodes.

Once the cluster had been deployed and configured, I created three virtual machines, which were similar to the ones I had used in my tests on the standalone Hyper-V server. I performed three tests against the cluster.

Figure G - Testing setup used for cluster environment.

Granular Restore Test

The first of these tests was a granular restoration of some files from a clustered virtualized file server. The test was performed in exactly the same manner as when I tested a granular restoration of a virtual machine running on a standalone Hyper-V Server. As expected, the test yielded exactly the same results, with the granular restoration working perfectly.

Loss of a Single Virtual Machine

The second test I performed was to see if I could recover a single clustered virtual machine. For this test, I deleted one of three virtual machines hosted on my Hyper-V cluster. After doing so, I also deleted the virtual hard drive file and the configuration files associated with the virtual machine.

Next, I opened the BackupAssist Restore Console, loaded my backup job, and selected the virtual machine that I wanted to restore. As a precaution, I also selected the folder on the shared storage array that contained the virtual hard drive file and the configuration files for the virtual machine. You can see my selections in Figure E below. In the figure, the Microsoft Hyper-V VSS section refers to the individual virtual machines, and Z: is the drive that was mapped to my shared storage array.

Figure E - BackupAssist is able to backup and restore clustered virtual machines.

When the restoration completed, the newly restored virtual machine appeared in Hyper-V Manager, and the associated files appeared in the correct location on the shared storage array. Hyper-V Manager showed the virtual machine as being turned off, as shown in Figure F, but I had no trouble starting it. Once the virtual machine started, I was able to log in to it and verify that it was functioning correctly. It is also worth noting that the virtual machine did not have to be reactivated.

Figure F - The virtual machine was restored, but had to be started manually.

Loss of Entire Cluster Node

For my last test, I wanted to find out what would happen if an entire cluster node failed and needed to be restored. For this test, I ran a Windows Imaging Backup job. I included the server's physical hard drives in the backup selections, but did not include the drive that was mapped to the shared storage array.

When the backup completed, I removed the hard drive from the server and replaced it with a brand new hard drive. I booted from the Windows Server 2008 R2 installation media and chose the option to perform a bare metal restoration. Windows had no trouble detecting the backup created by BackupAssist, and the restoration process completed without incident. The server booted and I had no trouble with any of the virtual machines.

Points to remember

The following is a summary of points to remember when using BackupAssist to back up your Hyper-V Host and Guest Virtual Machines.

Backup

· Do not select the Microsoft Hyper-V VSS option when making your backup selections in BackupAssist. This ensures that the 'Bare Metal Recovery' option is enabled for your image backup.

· Use the Hyper-V Config Reporter to create a HTML report of your Hyper-V Host and Guest Virtual Machine settings. This makes it easier to recreate a VM on a new Host.

Restore

· BackupAssist allows you to mount a virtual hard drive from a backup as a drive letter on the host server, but this drive it is not directly accessible from the virtual machine to which you are attempting to restore. You can, however, burn files to a DVD or share the folder on the network to transfer files.

· When restoring virtual machines to a different Hyper-V server running on dissimilar hardware, ensure that your restoration server has the same number of disks as the original server.

· When attempting to restore from an external hard drive, ensure that the external drive is mapped to the same drive letter as it was originally. For example, if the drive you backed up to was originally mapped to F: drive, ensure that the drive is mapped to the same letter when performing a restore.

· Even if the server to which you are restoring your virtual machines has a network adapter identical to the one on which the backup was made, the virtual network settings will need to be reconfigured after the restoration is complete. This is due to a Hyper-V limitation.

Pricing

BackupAssist is priced in a way that makes it affordable for small and medium sized businesses. The base price of a BackupAssist license is $249, with various add-ons costing extra. Although some may criticize this pricing structure as "nickel and diming", I think the pricing structure makes sense in the SMB market because it allows businesses to purchase only the modules that they need, thus keeping the price low. As of December 2010, the pricing for new BackupAssist licenses was as follows:

Additionally, BackupAssist offers a substantial discount to those who are upgrading from version 4 or version 5. Upgrades from version 4 to version 6 sell for $199, while upgrades from version 5 to version 6 cost $149. In both cases, add-ons can be upgraded free of charge. For this review, I used BackupAssist plus the BackupAssist VM Granular Restore Add-on, which would have had a total licensing cost of $498. By way of comparison, licensing Backup Exec in a similar manner would have cost over $3000 [2].

My Overall Assessment

In my opinion, BackupAssist is a must-have for small and medium businesses. Server virtualization has traditionally complicated disaster recovery, but this product cuts through that complexity and makes restoration a breeze. Throughout my tests the software never let me down regardless of whether I was restoring a host server, a virtual machine, or even a failover cluster node.

I think that what I really like most about BackupAssist is that it eliminates most of the guesswork from the disaster recovery process. Normally in a virtual machine environment an administrator must anticipate the types of failures that could potentially occur and then design a backup strategy that can cope with those failures. With BackupAssist, I simply configured a backup job without putting a lot of thought into it, and was able to use the same backup BackupAssist created in a variety of different disaster recovery situations.

I was also impressed that it is possible to buy such a flexible product at a reasonable price. Granted, I don't really think that BackupAssist would be appropriate for large enterprises because it lacks a central console for managing multiple servers, but I do think that BackupAssist is a product that no small or medium sized business should be without.

A 30 day fully functional trial, including the VM Granular Restore Console, is available from the BackupAssist Web site, so if you're looking for a backup solution for Hyper-V, I recommend you give it a try.

About the author

Brien Posey is a freelance technical writer who has received Microsoft's MVP award six times for his work with Exchange Server, Windows Server, IIS, and File Systems Storage.

Brien has written or contributed to about three dozen books, and has written well over 4,000 technical articles and white papers for a variety of printed publications and Web sites. In addition to his writing, Brien routinely speaks at IT conferences and is involved in a wide variety of other technology related projects.

Prior to going freelance, Brien served as CIO for a national chain of hospitals and healthcare companies. He has also served as a Network Administrator for the Department of Defense at Fort Knox, and for some of the nation's largest insurance companies.

http://www.brienposey.com