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

Build an asynchronous SnapMirror relationship

Peer, destination, policy, initialize, and monitor.

Scenario

Example: source svm_prod:vol_projects replicates to dr_svm:vol_projects_dr every hour. This is an example RPO, not a promise of zero data loss.

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. Prepare both sides

  1. Confirm ONTAP version compatibility, intercluster LIF reachability, DNS/routes, licenses, and destination capacity. Peer clusters and SVMs with the approved authentication process.
  2. Choose the relationship type and policy: mirror for DR, vault for longer retention, or a supported combined policy. Define schedule, retention, and the recovery objective.
Read-only checks 
cluster peer show
vserver peer show
network interface show

2. Create and initialize

  1. Create the destination volume with suitable capacity on the destination SVM. In System Manager, select the source volume, choose Protect, select the destination and approved policy/schedule, and create the relationship.
  2. Initialize the relationship. Baseline transfer can be large; monitor progress and network capacity. After completion, record source/destination path, relationship UUID, policy, lag and schedule.
Read-only validation 
snapmirror show
snapmirror show -fields health,lag-time,last-transfer-error

Worked CLI example: initialize the DR relationship

  1. Run relationship creation on the destination cluster after peering and destination volume preparation. Confirm the policy and schedule are available; this example uses MirrorLatest and a schedule named hourly.
  2. Initialize the baseline and monitor it to completion. The source path and destination path must match the approved worksheet.
Example change commands · destination cluster 
cluster peer show
vserver peer show
snapmirror policy show -policy MirrorLatest
job schedule show -name hourly
snapmirror create -source-path svm_prod:vol_projects -destination-path dr_svm:vol_projects_dr -type XDP -schedule hourly -policy MirrorLatest
snapmirror initialize -destination-path dr_svm:vol_projects_dr
snapmirror show -destination-path dr_svm:vol_projects_dr
Verify

Baseline is complete, relationship is healthy, and the latest transfer meets the agreed RPO.

3. Monitor and test

  1. Check relationship health, last transfer error, and lag against the RPO daily. A healthy relationship with excessive lag may still miss the objective.
  2. Plan a non-disruptive failover test with a clone or isolated environment where supported. Document application dependencies, client DNS and routing changes, and failback.
Verify

Relationship healthy; baseline complete; observed lag within the agreed RPO.

If validation fails

  1. If initialization fails, read last-transfer-error and check peering, intercluster LIF connectivity, compatible policies, destination space and source volume state.
  2. If health is good but lag exceeds the RPO, compare schedule to transfer duration and investigate network bandwidth and change rate.
  3. If destination snapshots are missing, compare source snapshot labels to destination policy rules and verify that a successful update has occurred.
Verify

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

NetApp references