SRM Failback Replication

[Goofoff]

Can someone please answer this quick question.

Using vSphere Replication and SRM

When doing a failback with SRM is there a way to get around doing a full resync back?

Can we do a Failover to DR then failback by just doing a Delta back?

Does it matter how the failback happens if the failover was Disaster Recovery or Planned in reference to the failback?

[basher]

Hello,

This is already happening. Probably you are confused by the term "Full Sync" you may be seeing in the UI. For vSphere Replication "Full Sync" means doing checksums at both ends and comparing the files. Only differences are then transmitted over the network.

It does not matter whether you used Disaster Recovery or Planned Migration to do the failover.

Best Regards

Stefan Tsonev

[Goofoff]

how about the first time after a reprotect?

Does it always do an "Initial Full Sync" then? or can you do the "Full Sync" with using the current disks as seeds?

[basher]

Yes, this happens after reprotect. We only do Full Sync (essentially using current disks as seeds).

Are you seeing "Initial Full Sync" after reprotect?

[Goofoff]

Yes, the outgoing replications is showing "Initial Full Sync"

and was just double checking that i wasn't hallucinating because i have done these before but with SAN replication, not vSphere replication, those showed Full Sync before.

I thought that was wrong but that is what i am seeing and am wondering what could/would have changed.

This is SRM/vSphere replication 5.8

Any idea what would cause the difference?

[Goofoff]

Anything?

[vbrowncoat]

Like Stefan wrote, the initial full sync when used with seed disks (as is the case when you reverse replication) run checksums and just sync changes. Running and comparing the checksums can take some time, especially if the disks are large. It doesn't matter that nothing or very little has changed because most of the time is going to running the checksums not transferring the data. Does that answer your question?

[Goofoff]

well the funny thing is that it was taking as long as the actual initial sync.

even 8 hours for the 2 tb volume.