Recovery Data and Applications with Zerto

By doing a failover test with Zerto features, we know that in a real disaster or disruption, everything is configured correctly and working as expected. Because if we put our VMs in a VPG, an entire multi-VM application can be rigorously tested without any interruption to that same application in production.

By clicking on the Failover button on the right bottom, we can start a failover test. The VPG can be ticked and click on next to continue.

[caption id="attachment_1884" align="alignnone" width="1158"]

Photo credits: Zerto.com[/caption]

The execution parameters are that which have been set up in the VPGs for example, boot sequence and checkpoint dates etc.. The Failover Test section is where you can start the Failover test.

The failover test creates VMs in a sandbox using the test network defined in the VPG settings. All testing is written to scratch volumes. The longer the test, the more space is consumed. At the end of the test, ZVR will power on the test VMs and do so in the correct boot order if one was specified.

The test will keep writing to scratch volumes until either:

The hard journal storage limit is reached
It's manually stopped.

[caption id="attachment_1885" align="alignnone" width="1137"]

Photo credits: Zerto.com[/caption]

Since Zerto automates the test cleanup, you should only stop a test from within a vSphere client. In a live environment, you would then verify the results of the test in the recovery site and ensure each VM is performing as expected. Assuming a successful test, you can come back to the ZVM and click "Stop" under the running task section.

[caption id="attachment_1886" align="aligncenter" width="394"]

Photo credits: Zerto.com[/caption]

The report tab provides detail on the test ran. This can be used for confirmation of test success or failure and aid in compliance. The recovery reports can also be exported in PDF.

A live failover test can also be performed. This is an example from where you can toggle from test to live failover.

[caption id="attachment_1887" align="alignnone" width="1192"]

Photo credits: Zerto.com[/caption]

I have to choose the VPG and click on next

[caption id="attachment_1888" align="alignnone" width="1158"]

Photo credits: Zerto.com[/caption]

The i click on the checkpoint field to choose the date.

[caption id="attachment_1889" align="alignnone" width="1157"]

Photo credits: Zerto.com[/caption]

As mentioned the date can be choosen as well as a recovery can be performed from the latest backup.

[caption id="attachment_1890" align="aligncenter" width="654"]

Photo credits: Zerto.com[/caption]

You can also choose if you want to auto-commit, auto-rollback or none.

Auto-commit - Selecting Auto-Commit means that after a designated time (Default is 0 minutes), Zerto will commit the failover which promotes the failed over VMs to the new live production servers. Once the failover is committed, the DR servers will need to be failed back to production once the production site is restored to keep any changes made on the servers while failed over. To complete this, Reverse Replication will need to be enabled to replicate the changes from the target site back to the production site.

Auto-Rollback - The Auto-Rollback option allows you to designate a time after the Live Failover (Default 10 minutes) for the failover to be rolled back to production. This works similar to a Test Failover as you have a window to test your servers and applications and then undo the changes. This will also remove any changes that were made on the servers while at the DR site and does not require reverse replication.

[caption id="attachment_1898" align="alignnone" width="1116"]

Photo credits: Zerto.com[/caption]

None - If you set ‘None’ for the commit policy, you will have the option to either Rollback or Commit the failover later in time. This may be used in a situation where your production site is down, but could possibly be brought back online quickly. You have the option to commit the failover if you do not foresee a time production will be back online. However if the option is quickly fixed you can perform a Rollback.

After settings parameters in the "Execution Parameters" settings, the failover can start.

[caption id="attachment_1899" align="alignnone" width="1160"]

Photo credits: Zerto.com[/caption]

The sucessful failover test can be viewed on the dashboard. A move (or migration) is a more graceful operation than a failover since it is a planned outage It's great for failbacks, preventive maintenance and site/hardware migrations. ZVM will gracefully powered down the VMs and then, as they are shutting down, grab the very latest copy of the data and use that instead of the journal. To move VPG, click on "actions" and "move VPG"

[caption id="attachment_1900" align="alignnone" width="1186"]

Photo credits: Zerto.com[/caption]

Then follow the same step by selecting the VPGs, but this time on the execution parameters, the VM need to be shutdown and click on "move"

[caption id="attachment_1901" align="alignnone" width="1142"]

Photo credits: Zerto.com[/caption]

After ZVR, has finished the commit and processed the VPGs, the move is done and we are back to the green circle which means the SLA has been met and the operation is successful.