Can Zerto Exclude Disks or Volumes From Replication?

This is an article about Zerto, the award-winning IT Resilience platform I was first exposed to in 2011 and loved so much that I joined the team in 2012. For help with any Zerto-specific terminology, see Zerto’s official product documentation.

Note: this post refers to Zerto Virtual Replication versions 6.x and earlier.

A customer asked the following:

I am trying to figure out if Zerto can completely ignore certain disks on a protected VM. We have database backup dump devices that we do not want to replicate. I realize there is a Temp Disk flag that can be set that will not replicate changes after Initial Sync but, from the documentation I have found, Zerto still appears to require an Initial Sync of that disk.

Zerto doesn’t have a feature to completely ignore a disk or volume in versions 6.x and earlier. Note that doesn’t mean the feature is present in later versions, it strictly means I’m limiting myself to the context of versions 6.x and earlier!

This doesn’t mean the task is impossible. It does mean you must start with an empty source volume when protecting the virtual machine (VM) in Zerto. Sounds easy enough though, right? As some applications don’t appreciate having their temp data files destroyed, you should verify with the application owner and/or vendor before trying the workaround below. This process also assumes you are starting with a VM that is not protected by Zerto:

  1. In the VM’s guest operating system (OS), follow the OS or application vendor’s process to empty the relevant volume of all data you wish to bypass from Initial Sync. This sometimes involves stopping any application from writing to the relevant volume and then deleting the files on the volume.
  2. In the Zerto User Interface, Create or Edit a Zerto Virtual Protection Group (VPG).
  3. Apply the configuration settings you intend to apply to the VPG but, at the Storage step of the Create/Edit VPG wizard, check the box labeled Temp Data for any/all relevant volumes:

    Create VPG wizard with Temp Data highlighted
    A VPG Wizard with the Temp Data feature highlighted
  4. Optionally, check the box labeled Thin if you wish to set the Recovery Volume to Thin Provisioned.
  5. Continue to apply any configuration settings you intend to apply to the VPG, and then click Done.

If you created a new VPG, the VPG will next undergo an Initial Sync. If you edited an existing VPG, the VPG will instead undergo a Volume Initial Sync. Regardless of Sync type, while the relevant volume won’t be ignored completely, you may notice the Sync time is shorter as it has been reduced by whatever time it would have taken to sync that volume back when all the data was present. Note I say, “may” because it’s possible Zerto will read the entire source disk, as is the case when the source disk is thick-provisioned.

The result of all this? If you applied step 5, the result is no space wasted on temp/swap data that is generally useless in a recovery event.

 

Upgrading VMware Tools on a Zerto VRA (Virtual Replication Appliance)

This is an article about Zerto, the award-winning IT Resilience platform I was first exposed to in 2011 and loved so much that I joined the team in 2012. For help with any Zerto-specific terminology, see Zerto’s official product documentation.

If VMware vCenter alerts you to VMware Tools being outdated on a Zerto Virtual Replication Appliance (VRA), what do you do?

Like many modern virtual appliances, the Zerto VRAs are unmanaged. In other words, they operate without a need for user management or intervention. Zerto VRAs are deployed with the version of VMware Tools that Zerto approves for that version of the VRA. The Zerto Virtual Manager (ZVM) software manages the VRAs and there is rarely a need to spend time or effort on them. All upgrades to the VRAs are done through the ZVM interface.

If you have an internal policy demanding specific VMware Tools levels and you’re unable to file an exception request for unmanaged devices, which is unusual as even major government and private-industry regulations such as HIPAA, PCI, SOX and others allow for exceptions provided they are appropriately documented, I suggest reaching out to the Zerto Support Team through the MyZerto portal.

Why Zerto Performs a Delta Sync After Failover

This is an article about Zerto, the award-winning IT Resilience platform I was first exposed to in 2011 and loved so much that I joined the team in 2012. For help with any Zerto-specific terminology, see Zerto’s official product documentation.

Whenever you perform a Live Failover of any Virtual Protection Group (VPG) in Zerto you’re given the option to enable a feature called Reverse Protection. If enabled, the Reverse Protection feature automatically transposes the VPG configuration after recovery is complete so you don’t have to do it manually. The end result is a VPG configured to put things back where they came from.

One step in the Reverse Protection process that surprises some Zerto users is a Delta Sync. They ask what is Delta Syncing, why is a Delta Sync happening when Zerto should have the same data at each site, and more.

For more about the Zerto Delta Sync operation, see this post on the MyZerto forum.

Zerto performs a Delta Sync as part of Reverse Protection because Zerto inherently distrusts that VPG’s source-site data after a Live Failover event. We as people sometimes fall into the trap of assuming the source data must match the recovered data. After all, the application was shut down as part of the failover process, or the failover only took a minute or two! That assumption is incorrect for several reasons.

First, you are not failing over to the current application state because Zerto replicates asynchronously. The data may only be a few seconds old, but a few seconds is not zero seconds. Next, although you may elect to shut down the source application as part of the Live Failover, Zerto does not replicate data created by that application after you initiate the failover process. This is because, from a product design perspective, the Zerto software doesn’t fall into the “best case scenario” trap I mentioned earlier. Between the shutdown and the recovery, any one of dozens of events may have happened to alter the source application data, storage configuration, or the storage array itself. Zerto assumes a worst-case scenario, that the source and recovery site data may not be the same, and then validates this assumption using a Delta Sync.

If you do want a perfectly-synced application recovery, you want to use the Move operation instead of Live Failover. As with a Live Failover, the software assumes the worst and performs a Delta Sync (assuming you don’t disable Reverse Protection as part of the Move). Unlike a Live Failover, a Move will synchronize any data created by that application in the last moments before it is completely shut down and then “moved” to the recovery site.