NetApp ONTAP SnapMirror: Setup, Monitoring and Troubleshooting

NetApp ONTAP SnapMirror is the backbone of data protection on AFF/FAS systems - it replicates volumes between clusters for disaster recovery, backup and migration. The typical first-time setup fails in the same places: peering not completed on both sides, SVM names mismatched, or the destination volume left offline. This guide covers the complete SnapMirror workflow - cluster peering, SVM peering, relationship creation, initialization, monitoring and the most common troubleshooting commands - with real ONTAP CLI.

Step 1: Cluster Peering

Run on the source cluster (cluster1) to initiate peering with the destination (cluster2):

cluster1::> cluster peer create -peer-cluster cluster2     -peer-initiator-addresses 10.0.0.2 -peer-username admin -peer-password ********
cluster1::> cluster peer show

Then approve on the destination side if needed. Verify with cluster peer show - the peering state should be peered on both clusters.

Step 2: SVM Peering

The SVMs (Storage Virtual Machines) must also be peered, and applications must be allowed:

cluster1::> vserver peer create -vserver svm1 -peer-vserver svm2     -applications snapmirror -peer-cluster cluster2
cluster1::> vserver peer show

Step 3: Create the SnapMirror Relationship

cluster1::> snapmirror create -source-path svm1:vol1     -destination-path svm2:vol1 -type DP     -schedule 5min -policy MirrorAllSnapshots
cluster1::> snapmirror initialize -destination-path svm2:vol1

-type DP is the data-protection (async) relationship type; -schedule 5min replicates every five minutes. snapmirror initialize does the initial baseline copy - this can take a long time for big volumes; monitor it with snapmirror show.

Monitoring Commands

cluster1::> snapmirror show
cluster1::> snapmirror show -destination-path svm2:vol1
cluster1::> snapmirror show -fields state,status,lag-time,last-transfer-end-time
cluster1::> snapmirror show-history -destination-path svm2:vol1

Pay attention to lag-time (how stale the replica is) and status (snapmirrored = healthy, transferring = baseline in progress).

Troubleshooting Common Failures

Recovery Operations

cluster1::> snapmirror quiesce -destination-path svm2:vol1
cluster1::> snapmirror break -destination-path svm2:vol1
cluster1::> snapmirror resync -destination-path svm2:vol1
cluster1::> snapmirror delete -destination-path svm2:vol1

break makes the destination writable (for DR cutover); resync re-establishes replication after the source comes back.

Best Practices

• Always monitor lag-time - it is the true health metric of async replication.
• Use 5-minute schedules for critical volumes, hourly for the rest.
• Ensure enough Snapshot reserve on destination volumes; SnapMirror depends on Snapshot copies.

Related: NetApp ONTAP performance monitoring commands and NetApp ONTAP day-to-day cheat sheet.

原文链接：https://docs.netapp.com/us-en/ontap/data-protection/