koya979 - Fotolia

How do you fail back to a production VM from a secondary VM in the cloud?

Among the factors to consider when failing back to an on-site production VM is virtual machine IP address modification.

The answer to this question depends heavily on the mechanisms that were used to create, synchronize and fail over to a cloud-based virtual machine (VM). Generally speaking, a few different things must happen to fail back.

First, the data must be moved back to the premises. If the VM is something simple like a Web server that links to a separate database server, the VM may not have any live data that has to be migrated. In other cases, a reverse replication operation might have to occur to bring the on-premises copy of the virtual machine up-to-date or a storage live migration (vSphere Storage vMotion) might be required.

Another consideration is whether the fail back occurs while the VM is online. If the VM runs throughout the failback process, the hypervisor will need to perform a memory synchronization from the cloud-based copy to the on-premises virtual machine.

Often it is necessary to modify the virtual machine's IP address to fail back. A cloud-based VM typically runs in an address space separate from the local virtual machine, so the VM must be assigned an IP address that is valid for its current subnet.

Keep in mind that virtual machine failover and failback can take a variety of forms. The steps listed here refer to a hypervisor-level failback, but you can also fail back at the application or guest cluster level.

Next Steps

Best practices for replicating VMs

Configuring failover settings for Hyper-V VMs

Develop a DR plan for virtual machines

Dig Deeper on Disaster recovery facilities - operations