Fail back from Azure to an on-premises site
This article describes how to fail back virtual machines from Azure Virtual Machines to on-premises VMware environment. Follow the instructions in this article to fail back your VMware virtual machines or Windows/Linux physical servers after they've failed over from the on-premises site to Azure by using the Failover in Site Recovery tutorial.
- Ensure that you have read the details about the different types of failback and corresponding caveats.
You cannot failback after you have either completed migration, moved a virtual machine to another resource group, or deleted the Azure virtual machine. If you disable protection of the virtual machine, you cannot failback.
A Windows Server 2008 R2 SP1 physical server, if protected and failed over to Azure, cannot be failed back.
If you have failed over VMware virtual machines then you cannot failback to a Hyper-v host.
Before you proceed, complete the reprotect steps so that the virtual machines are in a replicated state, and you can initiate a failover back to an on-premises site. For more information, see How to reprotect from Azure to on-premises.
Make sure that the vCenter is in a connected state before you do a failback. Otherwise, disconnecting disks and attaching them back to the virtual machine fails.
During failover to Azure, the on-premises site may not be accessible and hence the configuration server may be either unavailable or shutdown. During reprotect and failback, the on-premises configuration server should be running and in a connected OK state.
During failback, the virtual machine must exist in the configuration server database, or failback won't succeed. Therefore, ensure that you take regularly scheduled backups of your server. If there was a disaster, you need to restore the server with the original IP address, for failback to work.
The master target server should not have any snapshots before triggering reprotect/failback.
Overview of failback
After you have failed over to Azure, you can fail back to your on-premises site by executing the following steps:
Reprotect the virtual machines on Azure so that they start to replicate to VMware virtual machines in your on-premises site. As part of this process, you also need to:
- Set up an on-premises master target: Windows master target for Windows virtual machines and Linux master target for Linux virtual machines.
- Set up a process server.
- Initiate reprotect. This will turn off the on-premises virtual machine and synchronize the Azure virtual machine's data with the on-premises disks.
Once your virtual machines on Azure are replicating to your on-premises site, you initiate a fail over from Azure to the on-premises site.
After your data has failed back, you reprotect the on-premises virtual machines again, so that they start replicating to Azure.
For a quick overview, watch the following video about how to fail back to an on-premises site.
Steps to fail back
Before you initiate failback, ensure that you have completed reprotection of the virtual machines. The virtual machines should be in a protected state, and their health should be OK. To reprotect the virtual machines, read how to reprotect.
- In the replicated items page, select the virtual machine, and right-click it to select Unplanned Failover.
- In Confirm Failover, verify the failover direction (from Azure), and then select the recovery point (latest, or the latest app consistent) that you want to use for the failover. The app consistent point is behind the latest point in time and causes some data loss.
- During failover, Site Recovery shuts down the virtual machines on Azure. After you check that failback has completed as expected, you can check that the virtual machines on Azure have been shut down.
- Commit is required to remove the failed over virtual machine from Azure.Right-click the protected item, and then click Commit. A job will remove the failed over virtual machines in Azure.
To what recovery point can I fail back the virtual machines?
During failback, you have two options to fail back the virtual machine/recovery plan.
If you select the latest processed point in time, all virtual machines will be failed over to their latest available point in time. In case, there is a replication group within the recovery plan, then each virtual machine of the replication group will fail over to its independent latest point in time.
You cannot fail back a virtual machine until it has at least one recovery point. You cannot fail back a recovery plan until all its virtual machines have at least one recovery point.
A latest recovery point is a crash-consistent recovery point.
- If you select the application consistent recovery point, a single virtual machine failback recovers to its latest available application-consistent recovery point. In the case of a recovery plan with a replication group, each replication group recovers to its common available recovery point. Application-consistent recovery points can be behind in time, and there might be loss in data.
What happens to VMware tools post failback?
In case of a Windows virtual machine, Azure Site Recovery disables the VMware tools during failover. During failback of the Windows virtual machine, the VMware tools are re-enabled.
Reprotect from on-premises to Azure
After failback finishes and you have initiated commit the recovered virtual machines in Azure are deleted. Now, the virtual machine is back on the on-premises site, but it won’t be protected. To start to replicate to Azure again, do the following:
- In Vault > Setting > Replicated items, select the virtual machines that have failed back, and then click Re-Protect.
- Give the value of the process server that needs to be used to send data back to Azure.
- Click OK to begin the reprotect job.
After an on-premises virtual machine boots up, it takes some time for the agent to register back to the configuration server (up to 15 minutes). During this time, reprotect fails and returns an error message stating that the agent is not installed. Wait for a few minutes, and then try reprotect again.
After the reprotect job finishes, the virtual machine is replicating back to Azure, and you can do a failover to move your virtual machines to Azure again.