In Quantum Mechanics, Schrodinger’s Cat makes light of the uncertainty that the state of an object’s property is in until the object is observed. The same can be said of data backup and recovery. As an IT manager, you know that your backups are in a quantum state until you perform a recovery or a disaster recovery simulation. Fortunately, Hyper V Replica make DR simulations and testing easy.
If disaster strikes, Hyper V replica is a great tool to have when you need to get back up and running quickly. In this post, we will simulate a disaster and go through the steps necessary to get things running again. Here’s what you will need:
- A pair of 2012 servers running Hyper V 2012.
- A virtual machine that is using Hyper V replica to replicate itself.
- A replica set that is functioning, up to date and has been tested.
For our scenario, we will assume the primary server has a two VM’s that are being replicated to a DR remote site server using Hyper V replica. One is a DC and the other is an application server. Let’s pretend that the primary server is in a building that’s adjacent to a dynamite factory and a tornado seed mill. You know what happens next! Luckily, no one gets hurt. But the primary servers are off line and you need to get the network running ASAP!
From the remote DR backup server, open Hyper V Manager and locate the virtual machine replica VM’s. Right click on each one and select ‘failover’ from the replication menu. The VM’s will start and your servers should have relatively recent copies of their respective data.
Yes, believe it or not, it’s that easy! The hardest part will be giving users access to the data at the DR site. For example:
- You may have to change DNS settings to point FQDN’s to the DR site’s public IP addresses.
- You may have to change internal DNS records and LAN subnets if the DR servers are in a different subnet.
- You may have to set up VPN or Terminal Services to give users access to the DR server’s data.
- You may need DC, DNS or other roles at the DR site for authentication, resolution, et. al.
This should be part of your DR planning. You can learn more about what hurdles you might face post failover by performing a DR simulation.
Once you have corrected the problem with the primary Hyper V Replica you can use reverse replication to move the primary VM back. To do this, open Hyper V Manager on the DR server, right click on each VM and select ‘reverse replication’ from the replication menu. Follow the wizard prompts to move the production VM back to the main site’s Hyper V server.
Moving the Primary VM back to the Main Site’s Hyper V Server
It’s possible that you may need to rebuild a new server or that communications between the primary server and the backup server was severed. There could also be a conflict if the primary server comes back on line and is not aware that it is no longer supposed to be the primary replica server. In this case, you may not have the option to reverse replicate.
To correct this, remove the stale VM from the primary server by right clicking on it and selecting delete from the drop down menu. If you have configured a new Hyper V server server as the primary, make sure that the server is configured to accept incoming and outgoing replications.
On the backup server, open the Hyper V manager and right click on the working VM to select remove replication from the replication menu. Once replication is removed, right click on the working VM again and select enable replication and replicate the VM to the primary server.
When replication completes, right click on the VM from the backup server and select planned failover. The planned failover will move the working VM back to the primary site server. If you open the replication health monitor, the backup server should list the VM as replica under the replication type.
