The Failover Live Process

Use the Failover operation following a disaster to recover protected virtual machines to the recovery site.

Note:

You can also move virtual machines from the protected site to the recovery site in a planned migration. For details, see Migrating a VPG to AWS.

When you set up a failover you always specify a checkpoint to which you want to recover the virtual machines. When you select a checkpoint – either the last automatically generated checkpoint, an earlier checkpoint, or a tagged checkpoint – Zerto makes sure that the virtual machines on AWS are recovered to this specified point-in-time. By setting a commit policy that enables checking the recovered machines before committing the failover, you can check the integrity of the recovered machines. If the machines are OK, you can commit the failover. Otherwise, you can roll back the operation and then repeat the procedure using a different checkpoint.

The Failover operation has the following basic steps:

•

If the protected site or Zerto Virtual Manager is down, the process continues with the next step.

If the protected site or Zerto Virtual Manager is still running, the failover requirements are determined:

•

If the default is requested, doing nothing to the protected virtual machines, the Failover operation continues with the next step.

•

If shutting down the protected virtual machines is requested and the protected virtual machines do not have a utility such as VMware Tools or Microsoft Integration Services available, the Failover operation fails.

•

If forcibly shutting down the protected virtual machines is requested, the protected virtual machines are shut down and the Failover operation continues with the next step.

•

The failover operation creates new instances on AWS in the production network and attaches each instance to its relevant EBS disks, configured to the checkpoint specified for the recovery. The new instances are created without CD-ROM or DVD drives, even if the protected virtual machines had CD-ROM or DVD drives. Also, 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.

The protected virtual machines are created as new instances in EC2. The default value for new instances in Zerto is m5.xlarge. If these instances do not meet your needs, you can change this value in the Policies tab of the Site Settings dialog, see Configuring Disaster Recovery Policies. You can also change the instance type of new instances when you create or edit a VPG.

Note:

The original protected virtual machines are not touched since the assumption is that the original protected site is down.

•

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 default is to automatically commit the Failover 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 failover, or rolled back, aborting the operation.

•

If the protected site is still available, for example, after a partial disaster, the original protected site virtual machines are not powered off and are not removed.