VMware Cloud Community
rushdirizvygmai
Enthusiast
Enthusiast

SRM reprotect after a DR Drill

Dear Gurus,

I had to encounter a query from a customer who is running a SRM environment for their DR.

His scenario is that for audit purpose he does a test DR drill and performs live transactions and commit the changes at the DR once it fails over.

Once they have done the transactions audit team asks the client to re-protect the vm and fail back at the same instance and to show them if those changes are reflected.

But SRM treats this as a full resync to reprotect where as rival software only replicates the changes.

This saves lots of time for them.

Is there a work around to this?

Best regards,

Rushdi

Tags (3)
Reply
0 Kudos
1 Reply
vbrowncoat
Expert
Expert

I'm guessing you are using vSphere Replication? I think you may be getting confused by the term "Full Sync" that VR uses. If so see this post about VR sync types: vSphere Replication Synchronization Types - VMware vSphere Blog

Specifically:

Full sync: With vSphere Replication versions 5.x, the entire contents of a source virtual disk (VMDK) and its target virtual disk are compared using checksums. This process identifies the differences between the source and target virtual disks. Comparing the source and target virtual disks requires reading the entire contents of each disk and the generation of checksums. Creating and comparing the checksums of the source and target require CPU cycles. While checksum comparisons are being calculated and compared, vSphere Replication will periodically send any differences that were discovered. The amount of time it takes to complete a full sync primarily depends on the size of the virtual disk(s) that make up a virtual machine, the amount of data that must be replicated, and the network bandwidth available for replication. A full sync occurs in a few scenarios: Most commonly, when replication is first configured for a powered on virtual machine — more on this in a moment — and if there is some sort of exception where vSphere Replication loses track of changes that have occurred at the source, which is far less common. vSphere Replication 6.0 introduced improvements to this process depending on the type of datastore and virtual disk format in use, which will be covered later in this article.

Reply
0 Kudos