In terms of virtualisation and disaster recovery, there are numerous options available to protect virtual machines that run on Microsoft Hyper-V.
Hyper-V is a feature of Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2 that provides native hypervisor capabilities to run virtual machines on the Intel x86-64 platform.
There are two options available to run Hyper-V – either as a role on one of the Windows Server releases above, or as Hyper-V Server, a free version of Windows Server that provides limited functionality.
With each release of Windows, Microsoft has added to, or improved, the general and data protection features in Hyper-V, with the current release providing functionality on a par with VMware vSphere.
While Hyper-V can be managed directly from any Windows 2008/2012 instance, many of the functions detailed below are supported under the centralised management tool, Microsoft System Center Virtual Machine Manager (SCVMM), currently at release 2012 R2.
Backup of Hyper-V guests is managed through the use of Volume Shadow Copy Services (VSS).
VSS – and specifically the Hyper-V VSS writer – provides the capability to suspend input/output (I/O) either on the hypervisor or in the guest (using Integration Services) while a snapshot and backup of the VM is taken.
There are many third-party backup systems available on the market that integrate with Hyper-V and VSS, including the ability to restore application data from inside the VM itself. As an alternative to using an independent software supplier backup product, Microsoft offers Windows Server Backup as a free tool to perform basic backup and recovery services.
It is important to note that Hyper-V provides VSS support inside a guest for Microsoft platforms only. This limits the effectiveness of the software when used with non-Microsoft guest operating systems.
It is also important to differentiate Hyper-V snapshots from VSS snapshots. A Hyper-V snapshot provides the ability to take a snapshot image of a running virtual machine. This redirects updates to a secondary (.avhd) file, and allows the VM to be returned to a previous state if desired. Hyper-V snapshots provide a local recovery point – for example, to revert a failed upgrade – not for backup or disaster recovery.
Hyper-V provides support for VM migration using the Live Migration feature introduced in Windows Server 2008 R2. This feature was an upgrade to Quick Migration and enables virtual machines to be moved between hosts with no outage or downtime.
The use of Live Migration in Windows Server 2008 R2 requires that each server is configured using Microsoft Failover Clustering and using shared storage for virtual machine files. There are also networking restrictions. Hosts must reside on the same subnet and are recommended to use a dedicated network for migration traffic.
The physical location of a virtual machine can be changed using Storage Live Migration, introduced in Windows Server 2012. This feature operates as its name suggests, moving the location of the guest files from one storage platform to another. Storage Live Migration operates either on a standalone Hyper-V server or in a Hyper-V cluster.
The release of Windows Server 2012 Microsoft also removed the need to use a clustered configuration, as long as the virtual machine is stored on an SMB file share. In addition, migrations can be achieved between separate Hyper-V instances not sharing storage, a so-called “shared nothing” live migration.
The choice of which migration tool to use will be dictated by performance capabilities of the network and storage, as well as the level of activity on the virtual machine – a very write-intensive VM may struggle to keep up with I/O replication over the network, for example.
There is also the issue of resiliency to consider. If shared storage is in place, then Live Migration makes more sense than “shared nothing” migration as all of the VM data remains on disk and updates are only made in one place. Obviously, Live Migration will complete faster than Storage Live Migration as only the memory and configuration details have to be transferred during the migration.
As discussed previously, VM migration itself is not a recovery tool, but does provide the ability to put in place the relocation of virtual machines in the event of some disaster recovery scenarios.
Hyper-V high availability/fault tolerance
Hyper-V provides the capability to implement high availability using cluster shared volumes and the failover cluster role in Windows Server. Shared storage can be achieved using either an iSCSI or fibre channel logical unit number (LUN), or using SMB 3.0 storage.
Read more about virtualisation and disaster recovery
- Computer Weekly runs the rule over the key areas of functionality in VMware that can help with disaster recovery, including VMware backup, migration, high availability and replication.
- Jon Toigo argues against virtualisation advocates that say the software-defined datacentre, with its high availability and clustering, does away with the need for disaster recovery.
Loss of a host in the cluster will cause any VMs to be restarted on another available node, with little, but no guarantee of, outage or impact to the users of the VM. Hyper-V provides no direct equivalent to vSphere Fault Tolerance, but does provide Hyper-V Replica.
Hyper-V VM replication
In Windows Server 2012, Microsoft introduced Hyper-V Replica, an IP-based replication feature that allows a virtual machine image to be copied asynchronously to a secondary location. In the event of a failure at the primary site, the replica copy can be started in the disaster recovery location.
The capabilities of Hyper-V Replica were extended with the release of Windows Server 2012 R2 to support replication to a third site, known as the extended replica. In the event of a loss of the primary site, the secondary and tertiary sites continue to replicate between each other, maintaining protection for the application.
The 2012 R2 also introduced a 30-second recovery point objective (RPO) for replicated VMs, compared with the five-minute value of Windows Server 2012.
Microsoft does not directly support SAN-based replication of virtual machines. However, external SAN-based storage or software, such as StarWind Virtual SAN, could be used to provide disaster recovery capabilities.
Hyper-V VMs are made up of VHD or VHDX virtual disks, plus a number of files that describe the configuration of the VM. If these files are placed on a shared LUN or volume, then the contents of the virtual machine can be replicated to another location and imported into a remote Hyper-V configuration in the event of a disaster. This process would require some manual scripting and management to achieve.
Hyper-V cloud replication and backup
One alternative to using a secondary datacentre is to push virtual machines into the public cloud. Microsoft operates its Azure cloud and provides facilities to move virtual machines to and from an on-premise Hyper-V deployment using Azure Site Recovery.
VM recovery is not limited to Hyper-V-based VMs, with additional support for VMware vSphere (5.x) and physical servers available. Microsoft claims RPO values as low as 30 seconds, although this will be dictated by bandwidth and latency. Replication techniques include Hyper-V Replica, SAN array-based replication and guest-based replication.
There are also a number of third-party replication systems that can be used to back up Hyper-V environments to the cloud. These include Zerto (Virtual Replication for Microsoft Hyper-V), which can replicate between hypervisor types (Hyper-V to vSphere) and uses a “data VM” to intercept and replicate I/O.
Another interesting system is from backup appliance supplier Datto. The Datto platform takes backups of virtual machines and, in the case of a failure of the primary system, allows the VM to be restarted in the Datto public cloud. Customers can run their application from the cloud until the primary VM and host has been recovered.