This content is part of the Essential Guide: Prepare and prevent: Virtual recovery and backup strategies
Problem solve Get help with specific problems with your technologies, process and projects.

Virtualized disaster recovery with host-level backups

Host-level backups are becoming a virtual disaster recovery best practice for more organizations. But this virtualized disaster recovery method can pose some challenges.

Host-level backups have gradually become a virtualized disaster recovery best practice and have gained in popularity compared with virtual machine-level backups. Host-level backups are key for virtual disaster recovery (DR), because they provide complete copies of all virtual machines (VMs) that reside on a host, including the operating system and its applications. The VM-level backups, on the other hand, rely on backups of individual VMs for virtualized disaster recovery.

With host-level backups, there's no backup agent on individual VMs. Instead, virtual hard disk and configuration files are captured to ensure consistency at the host level, then passed through the host to your backup medium of choice. For speedy virtual DR, hard disk and configuration files can be restored to the existing host or a replacement.

But some factors affect virtualized disaster recovery with host-level backups, so note the following workload conditions that arise from using this disaster recovery best practice.

Name resolution and directory services
For virtual disaster recovery, you need name resolution and an authentication source. Even applications that were unaffected by the failure might not work without an overarching authentication infrastructure, so time is of the essence. With name resolution and directory services, the restoration of virtual hard drive and configuration files through host-level backups can take as little as 10 minutes.

With Microsoft's Active Directory service, you can restore authentication traffic quickly by using multiple domain controllers. Starting with one domain controller from each domain allows you to regain functionality where roles could be seized using the Active Directory command-line tool ntdsutil. Once your infrastructure is restored, you can provision additional virtual domain controllers to increase authentication capacity. In a physical infrastructure, this procedure would take hours.

Keeping at least one domain controller from each domain as a physical server should be a disaster recovery best practice. Don't place all Active Directory domain controllers in the virtual infrastructure unless you place at least one on a standalone non-domain host.

Host-level backups for line-of-business applications
Line-of-business applications, such as healthcare, finance and inventory applications, can also be restored from host-level backups. Even if an application doesn't fit a virtual server because of resource requirements, you can still use this disaster recovery best practice to recover apps until additional hardware comes in.

But be careful with applications that rely on a MAC address for license verification. You can statically assign MAC addresses and get a new license code from your vendor, or you can use your current license code and set the VM MAC address to that of the destroyed physical server.

Host-level backups for databases
Restoring a database to a temporary location may not provide complete resource functionality, but it can be an adequate to way to access some of your critical data. In most cases, this requires restoring or reattaching a database, then ensuring that your name resolution allows client connections.

For Microsoft Hyper-V host-level backups, it is possible to have the Hyper-V Volume Shadow Copy Service writer and SQL writer coordinate the server and database for an online backup, but my results with this process have been inconsistent. I recommend taking flat file backups at least once per day, with at least one day of retention.

Virtualized disaster recovery for VDI and terminal servers
With virtual desktops, a common image can be created easily and accessed through a virtual desktop infrastructure (VDI) broker, such as Citrix XenDesktop or VMware View. Or, you can assign remote workers to a workstation hosted on a virtual server, using only a remote desktop client to connect.

Business applications installed on terminal servers can be placed on a virtual host to provide access to applications after a disaster. For users to regain access quickly, it's important to keep at least one VM up to date with your most critical applications and backed up with host-level backups. Using terminal servers with critical applications allows you to bridge the gap before physical servers are available.

Supportability and licensing for virtual DR
If you do not have the necessary licenses for any of these host-level backup methods, most vendors provide trial licenses that can get you over the hump. Note that in some of these scenarios, licensing could differ from your agreement with your vendors. Most vendors won't kick you when you're down, but it's important to acknowledge that during this time, you may stretch your end-user license agreement.

When virtual DR comes into play, you might be less concerned with whether a particular application is supported or recommended by your hypervisor vendor. You just need short-term functionality to meet the needs of your customers and avoid a financial loss. Think outside the box. A vendor might not support a certain application in a virtual infrastructure, but in the short-term, flexibility and speed of implementation are critical.

Host-level backups can ease virtual disaster recovery by restoring whole servers in a short period of time. To implement successful host-level backups, learn the tricks of this disaster recovery best practice.
If server virtualization or host-level backups helped speed disaster recovery in your infrastructure, share your disaster recovery stories here.

About the expert
Rob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at, writing tips and documenting experiences with various virtualization products.

This was last published in December 2010

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.