The use and capabilities of Hyper-V have grown rapidly since its introduction with Windows Server 2008. Hyper-V is now a feature-rich platform that is on par with VMware’s vSphere. Hyper-V has become an integral part of many businesses’ IT infrastructures. Establishing a disaster recovery strategy to protect your Hyper-V servers and virtual machines (VMs) is essential. A disaster is any event that renders your data center or server unusable. It is necessary to be able to minimize the downtime in the event a disaster hits your organization. Downtime can be very costly and being able to rapidly recover in the event of a disaster is vital. A recent study by Gartner calculated that the average cost of downtime for businesses was $5,600 per minute. Microsoft estimates that companies lose an average of $80,000 to $90,000 per hour of downtime.
Without a doubt, the most important Hyper-V disaster recovery feature is Hyper-V Replica. First announced with Windows Server 2012, Hyper-V Replica enables you to create a copy or replica of your mission-critical Hyper-V VMs on another Hyper-V host. When you enable Hyper-V Replica for a specific VM on the primary Hyper-V host server, the initial replication task will create an identical VM on the secondary Hyper-V host. After the initial replication completes, Hyper-V Replica will begin creating a log file of the changes to the primary VM’s VHDs. The log file is then periodically captured and forwarded to the secondary Hyper-V host according to the specified replication frequency. It is then applied to the replica. Hyper-V Replica gives you the ability to specify the number of recovery points you want to store for a given VM. Each recovery point represents a point-in-time from which you can recover the replicated VM. You can configure the replication frequency for every 30 seconds, 5 minutes, or 15 minutes.
With Windows Server 2012 R2 Microsoft introduced extended replication, which enables replication to a third site for additional DR flexibility. Extended replication allows you to have a closely located replica as well as a remote replica that could be in the cloud or in a remote geographical location. If an outage occurs, you can retrieve data from either the close replica or the extended replica. This provides an additional level of protection.
Hyper-V Replica failover is not automatic. You must manually initiate a failover. Hyper-V Replica supports three different types of failover:
• Test failover — You use the test failover option to check that a replica VM can start and run on the target host. This option will create duplicate test VM. It does not impact ongoing production replication. Following the test, the duplicate is deleted.
• Planned failover — You use the planned failover option to actually failover a VM to allow for planned downtime. You must manually turn off the primary VM before running a planned failover. After the planned failover completes, Hyper-V Replica will make the secondary replica the new primary replica. It will begin replicating the changes back from that replica to the old primary server. To restore the original primary server, you need to run a second planned failover.
• Unplanned failover — You use the unplanned failover option when unexpected outages occur on the primary VM. An unplanned failover is run from the replica VM. The primary VM will be unavailable. If you have enabled multiple recovery points, you can elect to recover the replica VM to a previous point in time.
Hyper-V Replica is a great option for protecting business-critical VMs from site or system outages. Unlike some third-party products, it does not provide automatic failover. However, it is built into Hyper-V, which makes it easy to setup and use for effective disaster protection.