The Failback (Move) Process
The failback process uses the MOVE wizard, following a disaster, to recover failed over virtual machines from AWS, back to the original site. You can initiate the MOVE operation from either the AWS site or the recovery site.
The MOVE process differs from a FAILOVER in the following ways:
■ You cannot select a checkpoint to restore the virtual machine to.
■ 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 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.
The Failback (MOVE) process has the following basic steps:
■ 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.
■ The data from the journal is promoted to the machines. The machines can be used during the promotion and Zerto ensures that the user sees the latest image, even if this image, in part, includes data from the journal.
■ If Keep Source VMs is not selected, the protected virtual machines are removed from AWS.
■ Based on the Instance Size and Type selected when creating a VPG from on-premise to AWS,upon failback from AWSto on-premise, the virtual machine will inherit the CPU and Memory from the selected AWSinstance.