Backing up VPGs to any 3rd party site

Zerto Announces 3.5 with Offsite Backup and Action APIs

For those focused on disaster recovery, business continuity, and all the fun and excitement that goes along with those activities – you’re in luck! Zerto has just announced the release of Zerto Virtual Replication 3.5. Here’s the scoop on what’s new and improved.

[symple_box color=”blue” text_align=”left” width=”100%” float=”none”]You can also take a trip back in time with my Take Two Zerto And Call Me In The Morning post from Virtualization Field Day 2.[/symple_box]

Offsite Backups

Zerto uses the Virtual Protection Group (VPG) name to define a group of virtual machines that are consistently backed up at the same time. Consistency is important for backups across multiple VMs. As an example, if you have an application server that believes it committed data to a database server, but the backup for the database server was taken before the application’s data was received, you’re going to have data gaps.

VPGs are replicated from a primary data center (the protected site) to the secondary data center (the replication site) by way of Zerto Virtual Replication appliances. With the new ZVR 3.5 Offsite Backup feature, a VPG can be replicated and backed up. Zerto adds a virtual backup appliance service to the Zerto Virtual Manager (ZVM) and utilizes a network share to store the backups.

This new option is revealed in the VPG configuration under the Recovery Policy drop down. There are now two options: Disaster Recovery and Extended Recovery. Disaster Recovery is the traditional Zerto process in which a VPG is replicated, while Extended Recovery also unlocks a number of other options for daily and weekly backups to a repository.

As shown below, the backup repository can be anything that talks SMB. This means it can be a local share, something off-prem, or even a storage target in a cloud provider. The choice is yours based on your budget, SLAs, and what makes sense for the use case.

Backing up VPGs to any 3rd party site
Backing up VPGs to any 3rd party site

The backup page contains everything necessary to restore the VPG, eliminating any dependencies on the source Zerto Virtual Manager (ZVM) and Zerto Virtual Replication (ZVR) appliances that originally created the backup. This boils down to being able to restore the VPG backup package to any Zerto environment you wish.

The guts of a Zerto backup package
The guts of a Zerto backup package

While this feature is excellent at extending the life of my VPG replication data by way of backups, it’s not a full featured backup product – and doesn’t pretend to be. There is no ability to do per-file or per-application restores, or even limit a VPG restore to a single VM. If you need features like that, you may still end up leveraging the Zerto offsite backups for helping to meet or exceed your SLAs for VPG restores, but would want to find a backup product that can specifically restore files or applications (Exchange, SQL, AD, etc.).

New Action APIs

I applaud the inclusion of new APIs for any product. Especially with DR … it’s one of those activities that you would really rather script / code against in advance, rather than worrying about manual intervention when disaster strikes. Zerto has announced new Action APIs in version 3.5, in addition to their already shipping Reporting APIs, to help further automate the enterprise DR strategy. A list of new Action APIs are provided below:

  • Start / Commit / Rollback Failover
  • Start / Stop Failover Test
  • Start / Abort Offsite Clone
  • Create Simple VPGs
  • Get Task Status
  • Get Service Profile
  • Get ZORGs
  • Get Peer Site
  • Virtualization Site

Additional VPG Status Details

Virtual Protection Groups now have much more detailed status values that include a sub-status. For example, if a VPG is currently in the Initializing phase, the sub-status may offer details about the initial sync status. If the VPG’s RPO is not meeting the defined SLA, the sub-status will give a clue as to what is causing this, such as stopped replication or intense quantity of IOPS that exceeds the replication bandwidth allowed.

Overall, the following VPG statuses exist with informative sub-status details:

  • Initializing
  • Failing Over
  • Meeting SLA
  • RPO Not Meeting SLA
  • Not Meeting SLA

More information is always a plus, right? 🙂


It’s great to see Zerto once again raising the bar and thinking outside of the box. I’m a long time fan of their technology and have seen it deployed into multiple data centers successfully – in my mind, this is the Cadillac of DR/BCP. I’m definitely looking forward to tinkering around with version 3.5 in the lab to make requests to their Action APIs and create some offsite backups.