• This topic has 11 replies, 1 voice, and was last updated August 2, 2022 by Peter B.

Bitmap and delta sync

  • What’s the definition of “bitmap sync” and “delta sync”? What’s the differences/similarities between these 2?

    George, longer definitions are in the online help for Zerto and also in the admin guides, but the short version:

    • Bitmap Sync – when Zerto sites are disconnected or the ability to replicate is otherwise severely impacted, Zerto can track changes in a bitmap of pointers\references so that when the issue is resolved it can quickly bundle up those blocks that changed during the outage and ship them over to the relevant target journals
    • Delta Sync – when Zerto needs to verify disk integrity, for example in the event of a failover with Reverse Protection enabled, it will go through a checksum validation between the source and target disks and send any relevant missing writes from the source to the target

    Thanks Sean. I tried looking in the online help and Admin guide, which both referred to bitmap and delta syncs, but didn’t actually define what they were. But thanks again.

    George.

    Apologies for not being more clear and pointing the pages out. A long-form definition of Bitmap Sync can be found in the latest Zerto Virtual Manager vSphere Administration Guide which I’ve attached to this comment. Starting on page 158 under “Bitmap Syncing”, with Delta on the following page.

    Hope this helps!

    You should also be aware, that depending on the duration of the outage, what would of been a bitmap sync, can turn into a delta sync. If the outage is long enough, and the data change rate is high enough, the bitmap can only hold so much information, then it has to dump out, and a delta sync is then used to verify the integrity of the disk by doing a block check-sum comparison. That’s how it was explained to me anyway.

    one additional question

    the delta sync depends on the bandwidth speed right?

    I mean both but when configuring reverse protection the delta sync takes a long of  time but I assume if  we double the bandwidth between sites this delta sync time will reduce?

     

     

    Delta Sync relies on two things:

    1. Storage performance at source and target sites so we can compare disks

    2. Bandwidth availability so we can move any data that is missing from the recovered VMs back to the old source site

     

    Doubling bandwidth capacity will not necessarily impact performance at all, specifically if storage performance is the bottleneck. And vice-versa.

    Gene Gregory D

    Hi,

    Thanks for a very good information about bitmap sync and delta sync

    Would there be a logs where we can see why bitmap sync is happening?,

    because when i ask our network guys they don’t see any unusual traffic, and don’t see any unusual traffic coming from vSphere from the IO performance

     

    As far as I know, there is no way for us (customers) to view why a sync is happening. Zerto can pull logs and narrow down the cause. I have had them do that for me in the past, and in fact it helped me identify a storage performance issue that I needed to correct.

    In general, a bitmap sync is going to happen because enough data was written in such a short amount of time, replication couldn’t keep up and Zerto needs to do a sync to maintain integrity of the data. An example would be if I copy a 25GB file onto my replicated server. It will only take about 30-60 seconds to copy and write the data, but Zerto will have to go into a bitmap sync until that data is fully replicated. That’s just one example.

    Hope that helps.

    Another example for why you see a VPG going into bitmap sync even when your network guys can’t find anything wrong with the link is when a SQL server being protected with Zerto runs a maintenance plan that does a database backup onto a disk  that’s hasn’t been excluded from replication.

    I would like to add an interesting case of being stuck in bitmap or delta sync and a resolution. We are a provider and leverage vCloud.

     

    We recently had a customer build a parallel vcenter during an upgrade and migrated vcenter over. We followed best practice for transitioning their DR environment and cutting over (deploying new ZCC and pairing to that). Although everything was paired fine, doing a vpg from pre-seed would result in stuck delta sync, and a new vpg from scratch was stuck in bitmap sync. Everything was fine before.

     

    We looked at the tunnel on our side (an ASAv) an noticed a couple IPs getting warnings. Turns out those IPs were related to 2 new nodes they added on their side. There was the same exact /24 on each side of the tunnel so we had to put in a static route or each VRA IP and their ZVM IP, otherwise the traffic was switched to INSIDE on our end instead of OUTSIDE, going back to the tunnel.

    Basically, even if things are paired, it can still be a network issue. Find out exactly what changed, get a list of ZVM and all VRA IPs for each side and check routing tables and logs from ASA, firewall hw, etc for errors.

    Nick S – Thank you for your post. We are experiencing a very similar issue that I have been troubleshooting for WAY too long. Reviewing your post with our team and hopeful to find some duplicate addresses.

The forum ‘General Discussion’ is closed to new topics and replies.