One of the best disaster recovery features found in Hyper-V is the Hyper-V replica feature. First introduced in Windows Server® 2012, Hyper-V replica allows administrators to create standby copies of virtual machines (VMs) that can be easily activated in the event that something happens to the primary copy.
Initially, Microsoft designed the Hyper-V replica feature to replicate VMs to a secondary Hyper-V host. These replica VMs remain powered off, until they are needed.
In Windows Server 2012 R2, Microsoft enhanced Hyper-V replication by introducing an extended replication feature. Extended replication allows for the creation of two replicas. The idea is that administrators can maintain an on-site replica and a secondary replica that resides in a remote data center. Having an off-site replica helps to protect the organization against a data-center-level disaster.
Even though Hyper-V replicas are not designed to replace an organization’s backups, the replication feature does allow for limited point-in-time recovery capabilities. If a replica has been configured to maintain multiple recovery points, an administrator activating a replica can opt to roll the VM back to a previous point in time.
As useful as Hyper-V replicas are, however, there are two limiting factors that Hyper-V administrators need to be aware of. First, Hyper-V replicas are not based on Windows® failover clustering. If a Hyper-V virtual machine were to fail, the replica is not activated automatically. It is up to the administrator to activate the replica.
The second limitation that you need to be aware of is although replica VMs are kept in sync with primary VMs, this synchronization is not real time. The synchronization period is adjustable, but in most cases it is set to five minutes. This means if a replica needs to be activated, then up to five minutes of data could be lost.
Microsoft provides three different options for activating Hyper-V replicas. The first option is to perform a test failover. A test failover activates the replica in a sandbox environment for testing purposes. Administrators can log into the replica and verify its health, while the primary VM copy remains active and the replication process continues to function in the background.
The second option for activating a replica is to perform a planned failover. Planned failovers can be useful for reducing the load on the server that is hosting the primary VM copy. Planned failovers are also typically used in situations in which the host server that is hosting the primary VM copy needs to be taken offline for maintenance.
A planned failover is a graceful way of activating a VM replica without data loss. When doing so, Hyper-V gives you the option of switching roles so the primary copy of the VM becomes the replica, and the replica VM becomes the primary.
The third option for activating a Hyper-V replica is to perform an unplanned failover. An unplanned failover is used when the primary VM copy becomes incapacitated due to some sort of disaster. In this scenario, the VM replica becomes the primary VM, and any data that has not yet been replicated is lost. Usually, however, only the data created or modified in the last few minutes is lost.
Most IT professionals seem to regard failover clustering as preferable to using Hyper-V replication because a highly available VM can failover automatically. Even so, Hyper-V replicas are easier to configure, and in most cases, are also far less expensive to implement.
Additional reading on Hyper-V:
Brien Posey is a 13-time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities and has served as a network engineer for the United States Department of Defense at Fort Knox. Posey has also worked as a network administrator for some of the largest insurance companies in America.
You can follow Brien on Twitter® at @BrienPosey
To find out more about backup from SolarWinds MSP, click here
© 2018 SolarWinds MSP UK Ltd. All Rights Reserved.