NetApp ONTAP SnapMirror Create: DR, SnapVault and Sync Policies

Always create relationships from the destination cluster - this is the ONTAP convention and avoids source-side permission errors.

The reason for the destination-side convention is that the relationship is owned and managed by the destination. The source is passive: it exposes Snapshot copies and answers requests, but scheduling, retention and state all live on the destination. Creating from the source either fails outright or produces a relationship you cannot manage, so make destination-side creation a hard rule in your runbooks.

The schedule named with -schedule must already exist, and it must be a cron-style schedule rather than a SnapMirror policy of the same name. Create it first if it does not:

cluster_dst::> job schedule cron create -name my_daily -dayofweek "mon,tue,wed,thu,fri,sat,sun" -hour 1 -minute 0
cluster_dst::> job schedule cron show -name my_daily

The distinction between a schedule and a policy trips people up constantly. The schedule answers "when do transfers run"; the policy answers "what happens to the Snapshot copies that get transferred". Both are required, and a missing schedule produces a validation error at creation time, which is at least honest about the problem.

Step 3: Initialize and Verify

cluster_dst::> snapmirror initialize -destination-path svm_dr:volA_dst

cluster_dst::> snapmirror show -destination-path svm_dr:volA_dst

snapmirror show confirms the relationship state and the transfer progress. Common errors and their fixes:

• Relationship already exists - check with snapmirror show -destination-path ...; the relationship may already be active.
• Source volume ... not found - verify the SVM and volume names on the source with volume show -vserver svm_prod.
• Destination volume does not exist - create the destination volume first (or check the SVM name in your destination path).

Initialization is a full baseline copy and will take as long as it takes to move the entire dataset — an important planning detail, because incremental transfers afterward are dramatically faster. Watch progress without blocking the CLI by using the job status:

cluster_dst::> snapmirror show -destination-path svm_dr:volA_dst -instance
cluster_dst::> snapmirror status -destination-path svm_dr:volA_dst

The -instance view is worth knowing: it exposes the transfer size, elapsed time, lag time and the last Snapshot copy transferred, which is far more useful than the summary table when a transfer is running long.

Verifying the Relationship Is Actually Healthy

A relationship in Snapmirrored state is not automatically healthy. Three things need checking on an ongoing basis:

cluster_dst::> snapmirror show -fields state,status,lag-time,health
cluster_dst::> snapmirror lag show
cluster_dst::> snapmirror list-destinations -source-path svm1:volA

Lag time is the metric that matters operationally — it tells you how stale the destination is relative to the source, and therefore what RPO you are actually achieving (as opposed to what the schedule claims). A relationship with a 10-minute schedule and a 3-hour lag is failing transfers silently. Watch for the pattern where lag grows monotonically: that is usually insufficient network bandwidth or a source-side Snapshot churn problem, not a configuration error.

Transfer Policies, Throttling and Bandwidth Control

SnapMirror transfers will happily consume the entire available intercluster bandwidth, which matters on links that are also carrying production traffic. Two mechanisms control this:

cluster_dst::> snapmirror policy show -policy MirrorLatest
cluster_dst::> snapmirror modify -destination-path svm_dr:volA_dst -throttle 1000
cluster_dst::> snapmirror show -fields transfer-priority

Throttling caps throughput per transfer (in KB/s with the CLI value), and transfer priority lets ONTAP schedule lower-priority relationships behind higher-priority ones. For a large initial baseline over a shared WAN link, throttling is the difference between a replication project and an outage.

Also worth knowing: snapmirror restore and snapmirror update are the two on-demand operations you will reach for most often. snapmirror update triggers an incremental transfer immediately without waiting for the schedule, and snapmirror restore pulls specific files or an entire Snapshot back from the destination — which on a mirror relationship is how you recover from source-side data loss.

Failover and Failback

The DR relationship is only useful if you can actually break it. ONTAP distinguishes planned and unplanned failover:

# Unplanned (source is gone)
cluster_dst::> snapmirror break -destination-path svm_dr:volA_dst

# Planned failover (source available, quiesce first)
cluster_src::> snapmirror quiesce -destination-path ...
cluster_dst::> snapmirror failover start -destination-path svm_dr:volA_dst

After snapmirror break, the destination becomes a normal read-write volume and the relationship stops replicating. To restore protection you must resync, which reestablishes the baseline — plan for that time in your recovery objectives, because the resync of a large volume is not fast.

SnapMirror vs SnapVault vs SVM DR

The volume-level relationships described here are not the only option. A comparison helps pick the right tool:

• SnapMirror DR (MirrorLatest) — volume-level replica, fast failover, minimal destination space. Does not preserve long-term history.
• SnapVault (XDPDefault) — backup-oriented, retains many Snapshot copies on the destination, but the destination is not a bootable replica of the current state in the DR sense.
• Unified (MirrorAndVault) — both behaviours in one relationship; the usual choice for most production volumes.
• SVM DR — replicates an entire SVM, including configuration, volumes and SnapMirror relationships between them. Heavier, but it removes the need to rebuild an SVM by hand during recovery.

For most environments the answer is a tiered one: MirrorAndVault to a secondary site for tier-1 data, XDPDefault to a third location or to a cloud endpoint for long-term retention, and SVM DR where the recovery of an entire tenant needs to be automatic.

Monitoring and Automation

cluster_dst::> snapmirror show -fields lag-time | grep -v ":00"
cluster_dst::> event filter create -filter-name sm_alerts
cluster_dst::> event route add-destinations -filter-name sm_alerts -destinations smtp

ONTAP generates EMS events for lag threshold breaches and transfer failures, and routing them to email or syslog is the only way to catch a silently lagging relationship before it becomes an untested backup. Set the lag warning threshold to a multiple of your schedule interval — 2x is the common convention — so that a single missed transfer alerts without producing noise.

Related Reading on This Site

See the SnapMirror setup, monitoring and troubleshooting guide and the NetApp ONTAP CLI cheat sheet for surrounding commands.

For adjacent topics, the ONTAP Snapshot policy and schedule CLI guide covers the Snapshot policies that SnapMirror transfers actually depend on, and the ONTAP volume move and cutover guide is the natural companion when migrating a replicated volume between aggregates or nodes.

原文链接：https://docs.netapp.com/us-en/ontap/data-protection/create-replication-relationship-task.html