Important Things to Consider before Deploying Hyper-V Replication

Screenshot of a server rack.
Replication can be onsite or remote to help global availability.

Hyper-V’s replication feature allows firms to make their virtual machines highly available without the costs and complexities of physical replication. You may work at a multi-site company that needs to funnel through large quantities of data. Or your company can’t afford latency to disrupt the end-user experience. In these cases, you’d benefit from a Hyper-V replication server.

Virtualized replication servers allow you to create a digital copy of production servers and host them anywhere in the world and on the cloud. You can do this without worrying about hardware configurations matching the original system exactly, which is a time-consuming task. The administrator creates a copy and sends it off in discrete data packets created by the virtual machine (VM) or physically ships it on an encrypted and password-protected hard drive

In this article, I’ll discuss Hyper-V replication and how it works. To understand Hyper-V’s replication feature, first, you’ll need to understand what a replication server is!

What Is a Replication Server?

A replication server replicates a master server’s data. Scheduled updates or ad hoc requests push or pull data delta to each server. Data is checked against the master database for changes and then copied to the server that’s missing it. 

Data is often scheduled for out-of-hours replication to reduce disruption to operations. That said, if an end user is missing the data, then the server needing it creates an “ad-hoc” request. Depending on your requirement, you can also create daisy chain replication servers to improve this process.

To use a virtualized replication server, you’ll need to change the IP, fully qualified domain name (FQDN), and a few other settings to your specific application solutions to make each server unique. You can then periodically push or pull the data to replicas to update them. If local users are assigned to access a replica server and not the master server directly, they can pull new data through a request from the replica.

Even though setting up Hyper-V replication is normally a straightforward process, you’ll need to make several important decisions before deploying it. Let’s discuss 5 major considerations associated with setting up Hyper-V replication.

1. How Many Replicas Do You Need?

The first decision you’ll need to make regarding Hyper-V replication is the number of replicas you want to create. The more replicas you have, the less latency you’ll have, depending on the location of the replicas. You’ll also increase the number of users you’ll be able to cater to without “system downs” occurring.

If you decide to create a replica, it’s extremely important to ensure you have sufficient bandwidth. This is to confirm you can keep up with the change rate of the data being replicated.

2. How Much Data Can You Afford to Lose?

You can also use replicas to work as a backup. To do this effectively, you must consider how much data you can lose.

Replication aims to provide high availability for Hyper-V virtual machines. That said, some data loss is possible in certain situations.

When you create a Hyper-V replica, you create a duplicate Hyper-V virtual machine that’s in-sync with the primary copy your company is actively using. If something happens to your primary Hyper-V host or the virtual machine, you’d be able to transition to the replica environment, thereby avoiding a significant outage, known as a failover.

You can suffer 2 failover types.

1. Planned

This represents a graceful transition to the replica VM. If, for example, you needed to install some patches on your primary virtual machine host, you might perform a planned virtual machine failover before doing so. That way, you could reboot the host without disrupting your production workload. A planned failover doesn’t cause any data loss.

2. Unplanned

This happens when a catastrophic situation takes your primary virtual machine copy offline. You can quickly transition to the replica virtual machine in this situation. However, you’ll lose any data that hasn’t been replicated yet. 

This is why you should consider how much data you can afford to lose. When setting up Hyper-V replication, you must choose the replication frequency. Higher frequencies place a heavier load on a Hyper-V environment but result in less potential data loss in an unplanned failover.

Screenshot of the Configure Replication Frequency options in Mirage.
The replication frequency determines how much data you could potentially lose during an unplanned failover.

3. Do You Need Point-in-Time Recovery Capabilities?

Another consideration is whether you need point-in-time recovery capabilities. This recovery refers to your ability to roll back a virtual machine to a previous point in time. Normally, your backup software handles point-in-time recovery, which is usually best. 

However, you can configure your replica virtual machines to create hourly recovery points that last 24 hours. You’d use those replicas to roll back a virtual machine to a previous state. This makes it easier to recover from a ransomware attack. You can also create application-aware recovery points every 4 hours.

Screenshot of Configure Additional Recovery Points in Mirage
You can configure Hyper-V to provide limited point-in-time recovery capabilities.

4. Where Will You Store the Replicas?

It’s also important to consider where you’ll store your Hyper-V replicas. 

By default, Hyper-V will attempt to store replicas on the host’s C: drive. You’ll need to choose a location that has the required storage capacity. It should also deliver a sufficient level of storage IOPS (input/output operations per second).

5. How Will You Create the Initial Replica?

Another major consideration is how you’ll create the initial virtual machine replica. By default, Hyper-V will create the replica VM by copying the original virtual machine’s contents over the network. This can be impractical if you’re in a low bandwidth environment or if the virtual machine is really large. 

Hyper-V allows you to compress the data sent across the network if network bandwidth is a concern. You can also schedule the initial replication to occur during off-peak hours.

If you’re uncomfortable sending the initial replica across the network, you can create it by using external media (such as a backup tape). Another option is to use an existing virtual machine on the replica server as the initial copy

Screenshot of Choose Initial Replication Method options in Mirage.
Most organizations send the initial replica across the network.

Final Thoughts

Hyper-V replication is easy to configure. It can provide some failover capabilities to firms that may lack the budget or technical expertise typically required when building a failover cluster. Even so, you’ll need to do a bit of planning before attempting to configure the replication process.

You need to consider how many replicas you want to create. Generally, the more you create, the less latency you’ll have. You also need to consider how frequently you should update your replica. If you choose to update it less, you’d increase your chances of data loss if an unplanned failover happens. You also need to decide if you want to implement point-in-time capabilities. Your final consideration is where you’ll store your replicas. 

If you have more questions about Hyper-V replication, read our FAQ and Resources sections to learn more.


Will I lose data if I perform an unplanned failover?

You may suffer some data loss due to an unplanned failover. If you perform an unplanned failover, you’d lose any data you haven’t replicated.

When would I use an unplanned failover?

You should use an unplanned failover when the primary replica has become damaged or compromised, and you need to get back online quickly. This may result in losing a small amount of data. But it’s almost always faster to perform an unplanned failover than to restore a backup.

How do the replica servers authenticate with one another?

When you set up Hyper-V replication, you must choose an authentication type. You can choose between Kerberos (HTTP) and CredSSP (certificate-based authentication). Kerberos is best if you manage your servers remotely (via RDP). Still, if you decide to use Kerberos, it’s important, from a security perspective, to set up constrained delegation. 

What stops me from using replication with large virtual machines?

Microsoft supports using Hyper-V replication with multi-terabyte virtual machines. However, you should remember larger virtual machines need more time to create the initial replica.

Which virtual machines shouldn’t I replicate? 

A virtual machine with a high data change rate might not be suitable for use with Hyper-V’s replication feature. The replication engine may have trouble keeping up with all the changes. When that happens, the replication process stops. At best, you’d have to resume the replication process manually. Depending on how much data has accumulated, however, you may have to resynchronize the replica, which can be a lengthy process.


TechGenix: Article on Checking Hyper-V Health with PowerShell

Learn how to use PowerShell to maintain Hyper-V replication health.

TechGenix: Article on Azure Backup and Hyper-V Replication

Read about the role of Azure backup and Hyper-V replication.

TechGenix: Article on Replication in Other Microsoft Products

Discover replication options in other Microsoft products.

Microsoft: Article on Hyper-V Replication Deployment Prerequisites

Read more on the Hyper-V replication deployment prerequisites.

Microsoft: Article on Using Replicas For an Unplanned Failover

Discover what it means to use a replica for an unplanned failover.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top