Storage Admin HubConfiguration · Protection · Recovery
All guides/Disaster Recovery
Disaster Recovery · ONTAP 9

Execute volume-level DR failover and failback

Decision gates, destination activation, client cutover, and resync.

Scenario

Scenario: the primary site is unavailable and an asynchronous SnapMirror destination is the recovery target. Follow an approved application DR plan; the exact commands differ for SVM DR, synchronous, active sync, and MetroCluster.

Before you change production

Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.

1. Declare and assess

  1. Confirm incident authority, application owner, source-site status, last successful transfer, and likely data-loss window. Freeze writes to the source if reachable to avoid split-brain.
  2. Identify every volume the application needs: data, logs, boot, shares, LUNs, directory services, DNS, and network routes. Capture the destination snapshot and relationship state before activation.
Read-only decision checks 
snapmirror show
snapmirror show -fields health,lag-time,last-transfer-end-timestamp,last-transfer-error
volume show

2. Activate destination

  1. If the source is available, perform a final update or quiesce according to the recovery plan. If it is not, document the most recent transferred recovery point.
  2. Use the version- and relationship-specific NetApp failover procedure to stop scheduled replication and break the destination relationship. This makes destination data writable; do not do it during a routine health check.
  3. Bring up the DR-side data LIFs and access policies, map LUNs or expose shares, then shift client DNS/routing and start applications in dependency order. Validate with application transactions.
Verify

Recovery application is serving users at DR; known RPO loss and any failed dependencies are recorded.

3. Fail back deliberately

  1. Do not bring the old primary online with writes while clients use the DR copy. Decide the authoritative data set and obtain approval for the reverse replication direction.
  2. After source repair, resynchronize in the correct direction following NetApp guidance; resync can remove changes from the chosen destination. Validate data and application state before reversing client access.
  3. Restore the original protection direction, schedules and monitoring; perform an application acceptance test and close the DR timeline.
Verify

Exactly one writable production copy; desired replication direction healthy; clients at the intended site.

If validation fails

  1. If the primary may still be writable, stop before activating a second production copy. Establish fencing and a single authoritative data set with the incident commander.
  2. If DR data is accessible but the application fails, check dependencies such as DNS, AD, database logs, network routing and service startup order.
  3. If resync requests a destructive direction, stop and document which side contains the latest valid writes. Have the application owner approve the chosen recovery point.
Verify

Re-run the original validation and record the observed result, exact error, time, and corrective action.

NetApp references