In Azure NetApp Files replication, what's the difference between resync and reverse resync?

Question

As part of a DR exercise, we broke pairing between primary and secondary regions. The DR replica is now being used successfully.

In reading over the documentation, and looking at the portal, there's a bit of confusion. The docs say that to re-establish replication, we need to:

1. Do a Reverse Resync at the Source, and wait for it to complete
2. Break peering at the destination
3. Do a Reverse Resync at the Destination, and wait for it to complete

We'll get to that when it's time to do that, but is this a new procedure? When we were first testing this out some months back, all we needed to do was a "Resync", and this replicated back to the Source, and replication successfully resumed.

Also, while the volume peering is broken, I see "Reverse Resync" at the Source volume, which I expect. But I also see "Resync" at the Destination. What does this do?

1. Resync back to the Source from the Destination?
2. Resync to the Destination from the Source (which shouldn't be because the Source should be R/O if the peering is broken)
3. Something different?

Answer 1

Hello @Steve Down

I understand your wonder

If we go to the Docs :
https://learn.microsoft.com/en-us/azure/azure-netapp-files/cross-region-replication-manage-disaster-recovery

The reverse resync operation synchronizes the source and destination volumes by incrementally updating the source volume with the latest updates from the destination volume, based on the last available common snapshots. This operation avoids the need to synchronize the entire volume in most cases because only changes to the destination volume after the most recent common snapshot will have to be replicated to the source volume.

The reverse resync operation overwrites any newer data (than the most common snapshot) in the source volume with the updated destination volume data. The UI warns you about the potential for data loss. You will be prompted to confirm the resync action before the operation starts.

In case the source volume did not survive the disaster and therefore no common snapshot exists, all data in the destination will be resynchronized to a newly created source volume.

And resync to the Destination is the step that reverses the replication direction.It will incrementally update the original source volume with changes from the current destination,

--

I hope this helps!

Kindly mark the answer as Accepted and Upvote in case it helped!

Regards

Answer 2

After a proof-of-concept, I've clarified the behavior of "Resync" and "Reverse" resync.

When replication peering is established, data flows from source to destination, and not destination to source. This is always true.

When peering is broken, "Resync" and "Reverse Resync" are available.

"Resync" re-establishes the peering in the original Source to Destination direction, and synchronizes the volumes. It will overwrite any changes you made in the Destination volume after the peering was broken (in a disaster recovery scenario where you did not want to retain the changes, for example)

"Reverse Resync" doesn't merely copy the data in the reverse direction, it swaps Source and Destination so that the peering is defined in the reverse direction. Then it synchronizes the volumes in the newly established direction.

The lack of clarity in the documentation comes from the fact that they tell you do Reverse Resync, then Break Peering, then Reverse Resync again to get things going the way they were before breaking peering. This procedure is correct, but they make reference to Source and Destination in the later phases of this that does not explicitly call out that the Source and Destination endpoints were SWAPPED, and so on the surface it doesn't make sense. Adding to the confusion, the Reverse Resync operation swaps the endpoints, but doesn't show that on the page, and the Refresh button doesn't show that - only a complete page load after a Reverse Resync will show this.

Answer 3

@Steve Down
I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer. Accepted answers show up at the top, resulting in improved discoverability for others.

Issue: In Azure NetApp Files replication, what's the difference between resync and reverse resync?

Solution: Customer shared - "After proof-of-concept, I've clarified the behavior of "Resync" and "Reverse" resync.

When replication peering is established, data flows from source to destination, and not destination to source. This is always true.

When peering is broken, "Resync" and "Reverse Resync" are available.

"Resync" re-establishes the peering in the original Source to Destination direction and synchronizes the volumes. It will overwrite any changes you made in the Destination volume after the peering was broken (in a disaster recovery scenario where you did not want to retain the changes, for example)

"Reverse Resync" doesn't merely copy the data in the reverse direction, it swaps Source and Destination so that the peering is defined in the reverse direction. Then it synchronizes the volumes in the newly established direction.

The lack of clarity in the documentation comes from the fact that they tell you do Reverse Resync, then Break Peering, then Reverse Resync again to get things going the way they were before breaking peering. This procedure is correct, but they refer to Source and Destination in the later phases of this that does not explicitly call out that the Source and Destination endpoints were SWAPPED, and so on the surface it doesn't make sense. Adding to the confusion, the Reverse Resync operation swaps the endpoints, but doesn't show that on the page, and the Refresh button doesn't show that - only a complete page load after a Reverse Resync will show this."

---

If your issue remains unresolved or have further questions, please let us know in the comments how we can assist. We are here to help you and strive to make your experience better and greatly value your feedback.