Execute volume-level DR failover and failback

01Identify the authoritative copy and the recovery decision

A source outage and a lost intersite link are different events. During a link failure the source may still accept writes. Activating the destination for the same users without fencing can create two divergent datasets. The recovery decision needs an incident/change owner who can establish where new writes are allowed.

1. Record source availability, destination relationship state, last completed recovery point, application dependencies and the intended writer site. Obtain the application owner’s decision on any missing data.
2. For planned cutover, stop all source writers: application services, scheduled tasks, user mounts and background integrations. Verify the stop rather than relying on an announced maintenance window.
3. For an unplanned event, establish fencing or equivalent source isolation before allowing destination writes. If the primary state is unknown, escalate the decision; a storage command cannot establish business authority.

02Measure RPO from the completed point

Use the last completed usable recovery point rather than merely the transfer start time or a healthy flag. If a usable point is 14:00 and the source stops at 14:12, this example’s data age is 12 minutes. A transfer still running at 14:12 does not yet prove a later recoverable point. For a database, verify the coordinated application snapshot/log boundary; a crash-consistent storage point is not automatically an application-consistent point.

snapmirror show -destination-path svm_dr:vol_projects_dr -instance
volume snapshot show -vserver svm_dr -volume vol_projects_dr

03Complete the final update for a planned cutover

1. On the destination cluster, request a final update after source writers stop. Wait for completion and examine errors. A command accepted by the CLI is not proof that transfer completed.
2. Recheck the common recovery point and the transfer state. If the final update fails, keep writers stopped while deciding whether to fix it, cancel the cutover, or proceed with an explicitly accepted older point.
3. Quiesce scheduled transfers only when the transfer state and recovery point are acceptable. Do not use quiesce as a replacement for stopping source application writes.

snapmirror update -destination-path svm_dr:vol_projects_dr
snapmirror show -destination-path svm_dr:vol_projects_dr -instance
# After transfer completion and the accepted recovery point are verified:
snapmirror quiesce -destination-path svm_dr:vol_projects_dr

04Activate storage and move client access deliberately

1. Break only the intended asynchronous volume relationship after the single-writer and recovery-point gates pass. Verify the destination volume becomes writable.
2. Apply the pre-reviewed destination junction, export/share access and client endpoint plan. Check DNS TTLs, mount/UNC references, routing, identity, certificates and dependent services. Do not reuse a source address at another site without a network design that supports it.
3. Start dependent services in their documented order and permit application writes only after destination access and consistency checks pass. Leave the original source isolated from production clients.

snapmirror break -destination-path svm_dr:vol_projects_dr
volume show -vserver svm_dr -volume vol_projects_dr
snapmirror show -destination-path svm_dr:vol_projects_dr -instance

05Validate the application and measure RTO

Start the RTO clock at the agreed service-loss or declaration event and stop it at application acceptance. In a synthetic example, storage activation takes 4 minutes, identity/network changes 8 minutes and application recovery 13 minutes. Total observed service recovery is 25 minutes; reporting only the 4-minute storage stage would hide the actual operational recovery time.

06Reverse protection without overwriting the newest writes

After new writes at DR, the DR volume is the authoritative source for failback. Resynchronization can discard changes at the endpoint that becomes the destination. Preserve any data that must survive and review the exact source/destination pair before executing a resync. This is a high-impact direction decision, not an alert-clearing action.

1. Repair the original site, keep its clients disconnected, and confirm compatible storage, capacity and a usable common snapshot. Use the documented reverse-resynchronization procedure to replicate DR changes back to the original volume.
2. Prefer the supported System Manager Reverse Resync workflow for the exact relationship and ONTAP release when appropriate. Review the on-screen direction and data-loss warning with the application owner. The intended direction at this stage is svm_dr:vol_projects_dr to svm_prod:vol_projects.
3. Wait until reversed protection is healthy and the original-site destination contains the accepted DR recovery point. If a common point is unavailable, plan an approved rebaseline or data reconciliation rather than guessing a force option.

Follow the linked resynchronization procedure for command syntax and supported relationship variants.

07Perform a second controlled cutover and close the exercise

1. Stop DR writers, complete the final reverse update, verify the accepted point and activate the original-site volume according to the supported failback sequence. Redirect clients and test the application again.
2. Re-establish the intended original-to-DR relationship only after the original site is again authoritative. Monitor the first completed protection cycle.
3. If the pilot is cancelled before any DR writes, restoring original client routing may be a straightforward rollback. After DR writes, returning clients without reconciling data is a new recovery event that requires explicit direction and point-in-time decisions.