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.

This is the operational walk-through: what to build, in what order, and how to tell whether it is healthy. Every step below assumes you are logged into the cluster CLI as an administrator, and that the source and destination clusters already have a working IP path between their intercluster LIFs.

Before You Start: Prerequisites and Planning

SnapMirror failures are usually decided before the first command is typed. Confirm these five things first, because each one produces a distinct and easily recognisable failure later:

• Licences. SnapMirror must be licensed on both clusters: system license show -package snapmirror.
• Intercluster LIFs. Each cluster needs at least one intercluster LIF per node that will host replication traffic, on the cluster's admin network rather than the data network.
• A routable path. The intercluster LIFs must reach each other directly; intercluster traffic is not routed through the data LIFs.
• Consistent time. SnapMirror compares snapshot timestamps and schedules between the two clusters; if they show an unhealthy clock offset, transfers can be refused.
• A matching plan. Know the source volume, the destination SVM name, the destination aggregate, the RPO target, and whether the relationship is a plain volume mirror or needs SVM-level DR (XDP with identity preserve).

Intercluster LIFs are created like any other LIF, with the role set explicitly:

cluster1::> network interface create -vserver cluster1 -lif ic_lif1 -role intercluster \
            -data-protocol none -home-node node1 -home-port e0c \
            -address 10.0.0.11 -netmask 255.255.255.0
cluster1::> network interface show -role intercluster
cluster1::> network port show -role intercluster

Broadcast domains matter here: if the intercluster LIF is placed in a broadcast domain with a different MTU from the far side, the peering will come up but transfers will stall or fail intermittently. Record the MTU on both ends before you start peering, not after the first failed baseline.

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. On newer ONTAP releases the command prompts for a passphrase, which is the reciprocal authentication handle the remote cluster uses to accept the request; keep it in your password vault alongside the change record, because peering has to be recreated if it is lost.

cluster1::> cluster peer show -instance
cluster1::> cluster peer show -fields availability,authentication-status
cluster2::> cluster peer show

The Availability field is the one to watch: Available means the intercluster path is usable, Partial or Unavailable means at least one node cannot reach its peer, which is typically a missing intercluster LIF or a routing problem rather than a peering problem. Test reachability directly with a ping from a node in each cluster to the remote intercluster address before chasing the peering state.

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

cluster2::> vserver peer accept -vserver svm2 -peer-vserver svm1
cluster2::> vserver peer show

The direction of the peer relationship is not symmetric in the commands, and this is where first-time setups commonly stall: cluster peering is created once, but SVM peering is created by the SVM that will hold the source and accepted by the SVM that will hold the destination. If the destination relationship stays in initiated or pending, accept it on the other side rather than recreating it. For SVM disaster recovery the peering needs the snapmirror application (and, for full DR, a larger application set) — an incomplete application list blocks XDP relationships even though the peer shows as peered.

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.

cluster1::> snapmirror show
cluster1::> snapmirror list-destinations -source-path svm1:vol1

Before initializing, confirm that the destination volume exists, is online and is large enough. SnapMirror requires the destination to be at least as large as the source, and a relationship pointed at a volume that is offline or in a restricted state will sit in Uninitialized forever while reporting very little about why.

Understanding Relationship Types and Policies

List what your clusters actually ship with rather than assuming: snapmirror policy show prints the policy name, type, transfer priority and the Snapshot copy label and retention count per rule, and snapmirror policy show -instance expands the rules. Reusing an existing policy is almost always better than inventing one, because the label it stamps on transferred Snapshot copies determines the retention the destination enforces.

Step 4: Initializing and Monitoring the Baseline

The baseline transfer is the one operation where a quiet relationship is not necessarily a healthy one. Watch it from the destination side, which owns the transfer:

cluster2::> snapmirror show -destination-path svm2:vol1 -instance
cluster2::> snapmirror show -fields state,status,progress,last-transfer-size,last-transfer-duration
cluster2::> snapmirror show-history -destination-path svm2:vol1

During the baseline the state passes through Preparing, Transferring and Finalizing before landing in Snapmirrored. A progress value that stops advancing for a long period, or a state that returns to Preparing repeatedly, points at a link problem or an undersized destination rather than at ONTAP itself. For large volumes it is worth checking whether the destination aggregate has the free space to absorb the baseline plus the Snapshot copies that the policy will retain.

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).

cluster1::> snapmirror show -fields healthy,lag-time -destination-path svm2:vol1
cluster1::> snapmirror show -expand
cluster1::> volume snapshot show -vserver svm2 -volume vol1 -snapmirror-label *

The Healthy field is the fastest triage point in a large environment: healthy false with a healthy state means the relationship is up but lagging beyond the policy's lag threshold, which is an operational warning rather than an outage. The Expand view adds the transfer priority, Snapshot copy label and the retention rules that apply to each relationship, which is what you need when auditing whether the destination is actually keeping the snapshots you expect.

Reading Health: State, Status and Lag-Time

Lag-time is the metric that matters operationally, and it is measured in the same units as your RPO commitment. A relationship in Snapmirrored state with a lag-time growing past the schedule interval is not healthy in any useful sense, even though ONTAP considers the state nominal.

Troubleshooting Common Failures

cluster1::> event log show -severity error -message-name *SnapMirror*
cluster2::> snapmirror show-history -destination-path svm2:vol1 -instance

Two failure modes deserve emphasis. First, a vserver peer that is created but never accepted produces a relationship that advances through Preparing and then times out silently - always check the peer state on both clusters before touching the relationship. Second, retention rules are frequently the cause of "replication works but the backup is missing": the transfer completes, and the policy immediately expires the snapshot on the destination because no label matched a keep rule.

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.

Order matters. Quiesce stops in-flight transfers cleanly; break then detaches the destination so it can serve data; resync re-establishes the common base when the original source is available again, which is far cheaper than a fresh baseline because it reuses the shared Snapshot copies. Delete is destructive to the relationship only - it does not delete the volume - but it cannot be undone without recreating the relationship, so run it last. There is also snapmirror abort for stopping a transfer that quiesce cannot interrupt, and snapmirror resume to leave the quiesced state without breaking.

For restore operations, the destination holds Snapshot copies of the source volume, and ONTAP exposes them through the relationship:

cluster1::> snapmirror restore -destination-path svm1:vol1 -source-path svm2:vol1 \
            -source-snapshot daily.2026-09-01_0010
cluster1::> snapmirror snapshot-owner show -destination-path svm2:vol1

Advanced Topologies: Fan-Out, Cascade, SVM DR and Active Sync

Once a single relationship works, the same primitives compose into larger designs. Fan-out points one source volume at several destinations, which is the standard pattern for combining a short-RPO DR copy with a longer-retention backup copy. Cascade chains relationships so that a site with a slow link replicates from a regional hub rather than directly from a busy production cluster. SVM DR protects an entire SVM - its volumes, LIFs, export policies and configuration - using an XDP relationship with identity preserve, and its cutover uses vserver activate on the destination after the relationship is broken. SnapMirror active sync (formerly business continuity) goes further, combining XDP with an automated failover policy, consistency groups and a mediator so that failover can be transparent to hosts that are using multipath to both sites.

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.
• Test recovery, not just replication: a scheduled break on a non-production relationship is the only way to know the destination is usable.
• Keep the SVM peer and intercluster LIF configuration in the change record; these are the two components that cannot be reconstructed from the relationship itself.
• Standardise policy names across clusters so that audit output is comparable between sites.

Related: NetApp ONTAP SnapMirror configuration with the CLI, ONTAP Snapshot policy and schedule CLI and NetApp ONTAP day-to-day cheat sheet.

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