A failure of the main Hyper-V host usually means hours of downtime: either the server has to be repaired, or the VMs have to be restored from backup onto another server. If restoring from backup takes too long for your critical services, Hyper-V Replica is a simple, low-cost way to shorten that time.
What is Hyper-V Replica?
It is a Hyper-V feature in Windows Server that continuously and asynchronously replicates a virtual machine to another Hyper-V host. The VM on the destination server stays powered off, and only disk changes are sent to it at regular intervals. If the primary server fails, you start the destination VM.
Unlike a Failover Cluster, it does not require shared storage or identical hardware. The destination server can be in the same server room, in another branch or in a data center.
Main components and settings
- Replica server: On the destination server, you enable incoming replication in the Hyper-V settings and specify which servers it accepts replication from and where the data is stored.
- Authentication: There are two methods. Kerberos over HTTP is simple for domain-joined servers, but it does not encrypt replication traffic. Certificate-based authentication over HTTPS encrypts the traffic and is suitable for crossing untrusted networks or for servers outside the domain.
- Replication frequency: In recent versions of Windows Server, you can choose between 30 seconds, 5 minutes and 15 minutes. A shorter interval means less data loss, but more load on the network.
- Recovery points: In addition to the latest copy, you can keep several hourly recovery points and periodically take application-consistent copies (using VSS), which matters for databases.
- Initial replication: The first copy is a full one and can be sent over the network, on an external disk, or onto a VM already restored at the destination. For large VMs and slow links, scheduling it during off-peak hours or using the external disk method helps.
If the hosts are in a Failover Cluster, you configure the Replica Broker role for the cluster instead of a single server.
Three types of failover
- Test Failover: A test copy of the VM is created at the destination without interrupting replication. It is the best way to confirm everything works; just connect its network adapter to an isolated network so it does not conflict with the original VM.
- Planned Failover: For a planned move; the primary VM is shut down, the remaining changes are sent, and the VM starts at the destination with no data loss. You can then reverse the direction of replication.
- Failover: For a real failure, run on the destination server. Changes made after the last successful replication are lost.
Before a crisis hits, define the VM’s network settings at the destination. If the destination network uses different addressing, Hyper-V lets you set an alternate IP address to use at failover time.
Common mistakes
- Not opening the required port in the destination server’s firewall; the Hyper-V Replica rules in Windows Firewall are disabled by default.
- Not having enough space at the destination for multiple recovery points.
- Never running a Test Failover.
- Ignoring Replication Health, which shows when replication has fallen behind or stopped.
- Counting Replica as a backup. An accidental deletion or ransomware encryption reaches the replicated copy shortly afterward; an independent backup with older versions is still required.
Checklist
- Critical servers that need a short recovery time have been identified.
- The authentication method fits the connection path.
- Application-consistent recovery points are enabled for databases.
- Replication health is checked every day.
- A Test Failover is run every few months.
- A separate backup is still in place.
Hyper-V Replica greatly shortens the gap between a failure and restored service, at low cost. ITPlus724 engineers can set up and test replication of your VMs between your office, branches or data center.