Run a Real Failover

Following a disaster, use the failover operation to recover protected vApps to the recovery site. A real failover is the same as a test failover except the protected vApps are replicated back into the production network (depending on your configuration).


The Real Failover Process

The table below describes what happens during a real failover: 


Stage Description
Start the Real Failover

When you set up a real failover, you can:

  • Specify a check point to which you want to recover the vApps. The checkpoint is either the last auto-generated checkpoint, an earlier checkpoint, or a user-defined checkpoint. Zerto Virtual Replication ensures the vApps at the remote site are recovered to this specified point-in-time.

  • Check the integrity of the recovered machines by setting a commit policy that enables checking the recovered machines before committing the failover. 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.

During the Real Failover

During a real failover, the following events occur:

  • 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 vApps, the Failover operation continues with the next step.

  • If shutting down the protected vApps is requested and the protected vApps do not have VMware Tools or Microsoft Integration Services available, the Failover operation fails.

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

  • vApps are created at the remote site in the production network and each VM is attached to its relevant virtual disks, configured to the checkpoint specified for the recovery. The VMs are created without CD-ROM drives, even if the protected VMs had CD-ROM drives. The original protected VMs are not touched as it is assumed the original protected site is down.

  • VMs are prevented from being moved to other hosts: Setting HA to prevent DRS. This prevents automatic vMotioning of the affected VMs during the failover.

  • VMs are powered on to make them available to the user. If applicable, the boot order defined in the VPG settings is used to power on the machines. If the VMs do not power on, the process continues and the VMs must be manually powered on.

Commit the Real Failover

The default is to automatically commit the real failover without testing. However, you can also run basic tests on the VMs to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that you specify for the failover, the failover is either committed and finalised, or rolled back and failover aborted.


If the protected site is still available, for example, after a partial disaster, and reverse protection is possible and specified for the failover, the protected VMs are powered off and removed from the inventory. The virtual disks used by the VMs in the protected site are used for reverse protection. A Delta Sync is performed to make sure that the two copies, the new target site disks and the original site disks, are consistent. 


Note: If reverse protection is not possible, the original protected site VMs are not powered off and removed.


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: VMs cannot be moved to another host during promotion. If the host is rebooted during promotion, the VRA on the host must be running and communicating with the Zerto Virtual Manager before you can start up the recovered VMs.

Start a Real Failover

Follow these steps to start a real failover:


Note: If the VM you are protecting is still up and running, select VM shutdown. Then select Force Shutdown in vCloud Director.

1. From your target datacentre, open the Silver-lining DR self service portal. At the bottom right-hand side of the screen, set the operation to Live and click Failover.



2. The Select VPGs screen appears. Select the VPG name/s to failover, then Next. By default, all VPGs are listed. At the bottom of the screen, the selection details show the amount of data and the total number of VM's selected. The Direction arrow shows the direction of the process: from the protected site to the peer recovery site.



3. The Execution Parameters screen appears. Before you select a checkpoint for the failover, you can also set up reverse protection, and edit the failover commit policy. The table below describes how to do this.


Action Description
Set up Reverse Protection

Reverse protection can be configured to set up the job up in a waiting state. When the original source VPG becomes available again, it will use that as the Target and replicate back the other way. This provides an easy way to migrate back to the original VPG.


Follow these steps:


1. At the top right of the Execution Parameters screen, select Reverse Protect All.



2. The reverse protection symbol  will appear next to each VPG.

Edit the Failover Commit Policy

If a problem still occurs after booting up after a real failover, you can test the vApp to see if the problem still exists. For example, due to a virus, ransomware or malware. If the problem still exists you can revert back.


Follow these steps:


1. Select the VPG/s you want to edit.


2. At the top right of the Execution Parameters screen, click Edit Selected.



3. The Failover Commit Policy window appears. Use the drop-down menus to select a commit policy and the default timeout. Click OK.



4. While still on the Execution Parameters screen, select a checkpoint. By default, the latest checkpoint added to the journal is displayed. If you want to:

  • use this checkpoint, click Next and go to Step 8 below.
  • use one of the checkpoints from the last 3 days, click on the checkpoint that is displayed.


5. The Operations Checkpoints screen appears.  Select the Checkpoint you want to fail back to as a test and click OK.  To locate a specific checkpoint, use the table below.



6. To locate a specific checkpoint, select from the following options (as shown in the screenshot above).


Filter option Description

The recovery or clone is to the latest checkpoint. This ensures that data is crash-consistent for the recovery or clone. If a checkpoint is added between this point and starting the failover or clone, the later checkpoint is not used.

Latest Tagged Checkpoint

The recovery operation is to the latest checkpoint created manually. Checkpoints added to the VM journals in the VPG by the Zerto Virtual Manager ensure that data is crash-consistent to this point. If a checkpoint is added between this point and starting the operation, this later checkpoint is not used.

Select from all available checkpoints By default, this option displays all checkpoints in the system.
Refresh the list.


7. The Execution Parameters screen reappears showing the selected options checkpoint. Click Next.


8. The Failover screen appears. The topology shows the number of VPGs and vApps being failed over to each recovery site. In the following example, two VPGs will be failed over to the WPD2 site, and contain 4 vApps.



9. Click Start Failover. The failover begins an initialisation period, during which the vApps are created in the target (recovery) site.


10. The Silver-lining DR self service portal shows 'Failing over - before commit' in the Operation column of the VPGs being tested, and at the bottom left of the screen.



11. Once the failover has completed, the vApps will appear in the target site.


vApp at the target site during a live failover:


VPG state during a live failover:

Note: By default, this VPG will commit itself after 60 minutes, removing the vApp on the source site.


Monitor a Real Failover

Follow these steps to monitor a failover:


1. In the Silver-lining DR self service portal, click the VPGs tab to monitor the status of the failover.


2. In the General view, the Operation field displays 'Failing over - before commit' and the completion percentage.



3. Click on the name of a VPG you are failing over. A dynamic tab is created displaying the specific VPG details including the status of the failover.


Commit a Real Failover

Depending on the commit/rollback policy that you specified for the failover, the failover will be either committed and finalised, or rolled back and failover aborted.


Note: A commit will happen automatically if no user action has been taken in over 120 mins. 


Follow these steps to commit a real failover:


1. In the Silver-lining DR self service portal, select the VPGs tab, then click the Commit icon  in the Operation column.



2After committing a failover, the vApps will be replicated into the recovery site. Login to vCloud PAYG at the recovery site confirm that the VMs are visible.


A notification will appear in the Recent Events panel on the CloudCreator dashboard.


The page cannot be found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please make sure you spelled the page name correctly or use the search box.