FEATURE REQUEST - Speed Up the Planned Failback Process

[UBX_Cloud_Steve]

Six years have passed and currently this is still an issue even with v12.

Case #05982399

I just did some tests. With VMWare proxy setup at both source and destination “Calculating Original Signature Hard Disk” using hot add takes a tremendous amount of time.

3 hours per 500 GB of data. I believe that equals about 45 MB/s.

Our Pure Storage arrays reads at 2 GB/s-16 GB/s.
So I don’t think it’s the array.

We tried straight replication with and without CDP, and with or without cloud connect. All of them had similar results. So either something is missing or misconfigured or the fail back mechanism is has a design flaw.

[Seitjan]

9 years passed from the original post...Is @DrWhy still here?

@Gostev are you planning to do something with long "calculating disk signature" issue during failback?

I've testing right now 300 GB VM over 10Gbit link between sites (and 2 proxy each one on different sites) and it takes over 1 hours only to calculate disk, during first phase of Failback to production, and changes is only 1 text document on the Desktop! I'm wondering how long will it take during the second part after powering off the Replica VM and original VM.

It only little test VM, but we have about 60 critical VMs with SQL databases each one 1-3 Tb.

[Gostev]

According to the previous page, something was done 7 years ago when we enabled the product to leverage CBT data to determine changes instead of reading the entire disk image.

[YouGotServered]

Yes, but it didn't seem to work properly. I went back and forth with support for a loooong time before I had to abandon the case due to time investment. We had to move to another product for DR. Same issue - do a failover, almost immediately failback, and it would seem like CBT was totally ignored and everything was recalculated.

[Gostev]

Currently there doesn't appear to be any known issues with this functionality, so if anyone encounters similar challenges we would be happy to take a look.