• Preetam Zare

Part:11 Live Failover & Move Operation Procedures in Zerto

The Live Failover operation procedure highlights specific steps for a DR test. Complete explanation of DR and Move operation is mentioned over here. Here I’m explaining same steps in pictorial format.

Steps for Live Failover (Live DR) are same as Failover Test. Only difference you see is commit policy screen


In above screen you see Live button is toggled, Failover arrown becomes Red. Press Failover button to proceed. Select VPG you wish to failover shown in figure:01.

By default “Shutdown Protected VMs” is no. In Failover operation it is assumed VMs are already shutdown or not available. If you are doing simulate DR, you can manually shutdown the virtual machines. If you’ve good number of VMs you may evaluate a scripting option. Or you can use either “Yes” or “Force” option as shown below. I have used Force option.


If you use “Yes” option and VM doesn’t shutdown gracefully, entire process is aborted. Always use force option if unsure. If this is Simulate DR it is recommended to manually shutdown VMs.

For simulate DR it is recommended to Insert a new checkpoint. For more details on check point and how to take one, please refer here.This avoids potential data-loss since the VMs are shut down and the new checkpoint is added after all I/Os have been written to disk. In figure:02 You can see that I smartly named the checkpoint as “BeforeLiveFailover”

Let me digress here. I need to discuss Rollback and commit options. Both options can be executed automatically or manually. For automatic execution, All you have to do is provide how long you want either of the option to be executed. Maximum time by which you can delay rollback/commit option is by 24 hours.

Rollback allow us to go back to the same state before live failover. When all VMs are available in DR site, user can test application and save data. But rollback option was used, data won’t be saved. All changes made to the applications after live failover will be lost.

Commit is exactly opposite of rollback. All changes made when DR is activated will be saved. Therefore application state will change when you failback VMs.

There is very important thing to note. When you use commit option during move operation only you get to select whether you want to provide reverse protection (refer figure 14). If you don’t select reverse protection then all VMs at the protected site are lost. VMDK’s are deleted. So when you configure reverse protection later it is full sync and will delay VMs protection.

Ok, lets get back. Now you have to press final button i.e. Failover. Background is colored Red which indicates a Big Warning. If you read a text you will understand this operation permanently changes VMs at both protected and recovery site.


After pressing failover button VMs in the VPG are either shutdown gracefully or forcefully assuming you choose the appropriate option


In below screen DR is in progress.


Now lets see what happens at DR site. All VMs are in the process of being powered ON, reconfigured and booted according to the boot order. Failover Before Commit (recovery site) is completed.


During execution of this test I’ve de-selected Commit Policy option which is the reason you see that task name as Failover Before Commit.

Now that basic OS services are started, Application are accessible let end user test their applications. After successful confirmation from application users you can end the DR Live Test. Now it is time to failback DR back to protected site.

Rollback Option

I have done two tests here. One using rollback and other using commit option. Below I have shown screens of both the operations.


I first choose Rollback option. Rollback option simply powers off VMs (hard reset) and power ON VM at the recovery site. Nothing is saved. VMs are as good as they were before the DR simulation. Rollback option is kind of test feature, if VM doesn’t boot properly you can always rollback

Here is the view of recovery site


Commit Operation

Now lets see screens when you do a commit operation. Here you select commit option. Then you get option to select reverse protection.Failback procedure will use original disks are pre-seeded disk (automatically without specifying it). This will expedite the replication/ delta sync.

However as explain above in move operation this behavior is completely different and dependent on selection of reverse protection option


Reverse protection you can configure similar options in VPG as we did in during initial configuration of VPG here. All of them are same not much to explain.


Move Operation

User interface to initiate Move is almost same. You just need to select Move , Select VPG, press Next


Select Commit Policy which is same as Failover operation. In move operation you have only one option i.e. to force shutdown. If you don’t select it and one of VMs do not power off, operation is aborted. But you will see in failover operation you have option to select Shutdown VMs (No (default), Yes, Force). Refer Figure:02 at the top



In this process I have not select reverse protection and I have used commit policy. Therefore after you enable reverse protection full sync will happen.


Since we not selected reverse protection option all VMs at protected site got deleted which is an expected behavior.



Since all VMs must be synched. Below image shows the amount of data that is left to be synched.


If you wish to follow entire series of Zerto go to the Landing Page

Share this:

  1. Facebook

  2. LinkedIn

  3. Twitter

  4. WhatsApp

  5. Reddit

#DRaaS #virtualization #DR #vSphere #DisasterRecovery


©2019 by virtual2Cloud. Proudly created with