Query regarding Netapp files CRR replication

Question

Hi Team

I would like to seek some light on my below situation and appreciate if someone can guid me on this

We are trying a disaster recovery Exercise for newly built S4/HANA environment. We achieved a failover of VM's and NetApp files CRR replication at the DR site. Post functional team testing- We have fail backed to primary where we have HA setup in a primary region. Would like to understand in order to sync NetApp CRR back to Primary from Secondary how long it takes. Data must be around 11 TB. What is the best practise from Microsoft to initiate failback ?

Some people says when we do fail over to Secondary site and we need to wait on secondary for few days in order to sync correctly.

Answer 1

Hi Vishal Aadake,

Thanks for reaching out in Microsoft Q&A forum,

NetApp CRR (Cloud Replication Relationship) resynchronization time for 11 TB back to the primary site depends on network bandwidth, latency between Azure regions, and ongoing write activity during the DR stay.

For resyncing CRR from secondary back to primary after failback, the time isn't fixed but typically takes 24-72 hours for 11 TB, depending on inter-region bandwidth (aim for 1-10 Gbps effective), latency, and any ongoing writes monitor it closely with snapmirror show to hit under 5% lag before cutover. You don't need to wait "a few days" on secondary unless stabilizing heavy delta changes; best practice is to quiesce workloads post-testing, break the relationship, reverse source/dest roles (snapmirror resync from secondary), confirm sync, then re-establish original direction once primary HA is happy.

Microsoft's guidance aligns with Azure Site Recovery patterns: shut down secondary VMs if possible, during failback to minimize data loss, reprotect, and validate sync completion before traffic switch test this in non-prod first.

Official Docs:

• NetApp ONTAP SnapMirror Resync
• Azure Site Recovery Failback Tutorial

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

For Azure NetApp Files cross-region replication (CRR), there is no fixed, size-based failback time published for an 11‑TB dataset. The actual duration depends on:

• The amount of data that changed while running in DR
• The replication schedule configured (every 10 minutes, hourly, or daily)
• Network throughput and any replication lag

From Microsoft guidance:

1. Failover and failback are manual processes
   • For a region failure, failover requires breaking the peering and mounting the destination volume in the DR region. After the peering is broken, the storage-side failover itself typically completes within about one minute. Overall RTO is usually a few minutes to an hour, depending on how quickly the environment detects the issue and initiates failover.
   • After the primary region recovers, failback is also manual and requires:
     • Performing a resync operation
     • Reestablishing replication in the desired direction
     • Remounting the source volume for clients
2. Replication behavior and RPO
   • CRR is asynchronous; changes are replicated on the schedule configured:
     • Every 10 minutes (not supported for large volumes that use CRR)
     • Hourly
     • Daily
   • Typical RPO values are tied to that schedule (for example, 10‑minute schedule → typical RPO < 20 minutes). The longer the schedule, the more potential data loss in a disaster, but the less replication overhead.
3. Best-practice approach for failback
   Microsoft best practices for Azure NetApp Files DR with CRR are:
   • Plan and document the direction change: After failing over to DR and running there, when ready to fail back:
     1. Ensure the DR volume is in a healthy state and all application writes are quiesced before starting failback.
     2. Perform a resync from the DR volume back to the primary region volume to reestablish replication in the reverse direction.
     3. Once resync is complete and replication is healthy, perform the failback cutover by:
        • Breaking peering as needed
        • Mounting the now-active volume in the primary region to the application hosts
        • Redirecting application traffic back to the primary region
   • Traffic rerouting is the application owner’s responsibility: After failover or failback, application endpoints must be updated to point to the newly active volume.
   • Monitor replication health and lag: Use Azure Monitor metrics and the CRR health views to ensure replication is caught up before cutover.
4. “Waiting a few days” on DR
   There is no Microsoft requirement to stay on the secondary site for several days purely to “sync correctly.” The key requirement is that the replication relationship is healthy and fully caught up before performing failback. How long that takes depends on:
   • How much data changed while running in DR
   • The configured replication schedule
   • Any network or performance constraints
   For an 11‑TB environment, if the change rate is moderate and replication is healthy, failback can be performed as soon as the resync from DR to primary completes and monitoring shows no significant lag.

In summary, Microsoft best practice is to:

1. Use CRR with an appropriate schedule for the RPO/RTO targets.
2. On failback, perform a resync, verify replication health and lag, then cut over and remount volumes in the primary region.
3. Expect storage-side failover operations to complete in about a minute after peering is broken, with total RTO typically in the minutes-to-an-hour range for well-prepared configurations. The exact duration for 11 TB depends on change volume and environment throughput, not just raw size.

---

References:

• Reliability in Azure NetApp Files