The Failback (Move) Process

The failback process uses the MOVE wizard, following a disaster, to recover failed over virtual machines from Azure, back to the original site. You can initiate the MOVE operation from either the Azure site or the recovery site.

The MOVE process differs from a FAILOVER in the following ways:

■ To ensure data integrity during a MOVE, the protected virtual machines are powered off completely and a final checkpoint is created so that there is no data loss before the move is implemented.

When you perform a planned migration of virtual machines to a recovery site, Zerto Virtual Replication assumes that both sites are healthy and that you plan to relocate the virtual machines in an orderly fashion without loss of data. By setting a commit policy that enables checking the recovered machines before committing the Failback (Move), you can check the integrity of the recovered machines. If the machines are in the expected state and functioning correctly, you can commit the MOVE.

■ Creating the virtual machines at the remote site in the production network and attaching each virtual machine to its relevant virtual disks, configured to the checkpoint specified for the failback. As long as the virtual machines are created, the operation is considered successful, even if the virtual machines are not created with their complete definition, for example if re-IP cannot be performed.

■ Powering on the virtual machines making them available to the user. If applicable, the boot order defined in the VPG settings is used to power on the machines.

Note: If the virtual machines do not power on, the process continues and the virtual machines must be manually powered on. The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict or IP conflict, for example, if a clone was previously created with the MAC or IP address.

■ The default is to automatically commit the Failback (Move) operation without testing. However, you can also run basic tests on the machines to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that you specified for the operation, after testing either the operation is committed, finalizing the Failback (Move), or rolled back, aborting the operation.

■ If Reverse Protection to Azure using preseed is specified for the Failback (Move) operation, the original disks become the recovery disks and are moved into the recovery container. The virtual disks previously used by the virtual machines in the protected Azure site are used for reverse protection and the VMs are removed from Azure. The VPGs are reverse protected back to Azure, and a Delta Sync is performed as preseeding is supported.

■ The data from the journal is promoted to the machines. The machines can be used during the promotion and Zerto Virtual Replication ensures that the user sees the latest image, even if this image, in part, includes data from the journal.

Note: If Keep Source VMs is not selected, and the virtual machines, or vCD vApps are also protected in other VPGs, continuing with the operation will cause the virtual machines or vCD vApp to be deleted from other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.

■ Based on the Instance Size and Type selected when creating a VPG from on-premise to Azure, upon failback from Azure to on-premise, the virtual machine will inherit the CPU and Memory from the selected Azure instance.