ONTAP SnapMirror Guide: Async Replication, Policies, Schedules & Resync

How SnapMirror works

Every SnapMirror relationship is built on snapshots. An initialize copies one baseline snapshot to the destination over TCP (default port 11104 for the connection broker, 11105 for the data channel), then each update transfers only the WAFL blocks that changed between the source's newest common snapshot and the current one. Because the WAFL never overwrites blocks in place, an update is a bounded, incremental delta — not a re-copy. The destination keeps its own snapshot schedule on the mirrored copies, so recovery point granularity can be finer than the replication interval if you also snapshot at the destination.

Three phases define any relationship's life: baseline (full copy, size-dependent), steady state (scheduled incremental updates), and recovery (resync or failover). Almost all production pain lives in the transitions between them — plan the baseline window, the schedule, and the failure procedure before you create the first relationship.

Relationship types: DP vs XDP

Use XDP for everything new. Its two practical advantages: rule labels let one policy fan snapshots out to multiple destinations selectively, and version-flexible replication lets the destination run a different ONTAP version (see topologies).

Protection policies & rule labels

A policy is a named list of rules. Each rule says: for snapshots labeled X, keep N copies on the destination. ONTAP ships Default-5-minute, ASUP, Default (daily/weekly labels), Daily, Hourly, and the SnapMirror+backup hybrids. The labels on the source snapshot policy must match the labels in the SnapMirror policy rules — that's the whole matching mechanism:

# View shipped policies
snapmirror policy show

# Show the rules inside one
snapmirror policy show -policy MirrorAndVault -instance

# Create a custom policy: hourly mirror + daily vault
snapmirror policy create -vserver svm1 -policy app-mirror-vault \
    -type async-mirror -comment "hourly mirror + daily vault"

snapmirror policy add-rule -vserver svm1 -policy app-mirror-vault \
    -snapmirror-label hourly -keep 24
snapmirror policy add-rule -vserver svm1 -policy app-mirror-vault \
    -snapmirror-label daily -keep 30

On the source, the snapshot policy must actually create snapshots carrying those labels, or the destination rule has nothing to replicate and lag grows with no transfer activity:

snapmirror policy show -vserver svm1 -policy HourlySourceside  # example
volume snapshot policy show -policy app-hourly -instance

Schedules & lag-time math

Replication cadence is a cron schedule referenced by the relationship (or by the policy in newer releases). Steady-state RPO equals the schedule interval plus transfer time plus any backlog:

cron show -cluster cluster-01
cron create -name 15min-cron -minute 0,15,30,45
snapmirror modify -destination-path svm2:vol1_dst \
    -schedule 15min-cron

Worked example: a 15-minute schedule on a volume generating a 10 GB delta per hour over a link sustaining 250 MB/s: the transfer itself takes ~40 seconds, so healthy lag is 15–20 minutes. If lag-time climbs toward 45–60 minutes, either the delta grew (check source change rate) or the previous transfer never finished — scheduled updates skip while a transfer is in flight, so a saturated link converts directly into unbounded lag. Size replication bandwidth with the SnapMirror catch-up estimator before committing to an RPO.

Baseline initialization & throttling

The first transfer copies the entire volume (or the referenced snapshot). Three ways to keep it from strangling production:

# 1. Hard throttle during business hours (KB/s)
snapmirror modify -destination-path svm2:vol1_dst \
    -throttle 512000   # ~500 MB/s ceiling

# 2. Restrict the network the transfer uses
#    (intercluster LIFs on a dedicated VLAN/IPspace, see
#     cluster-peering for the full LIF design)

# 3. Seed from a snapshot instead of the active FS
snapmirror initialize -source-path svm1:vol1 \
    -destination-path svm2:vol1_dst \
    -source-snapshot nightly.0   # baseline from last night's snapshot

Monitor the baseline with snapmirror show -destination-path ... -fields status,progress; a long-running baseline restarts from the last checkpoint if interrupted, not from zero.

End-to-end CLI runbook

1. Peer the clusters (skip if already peered)

cluster peer create -peer-addrs 10.10.0.11,10.10.0.12
# exchange passphrases, then on the peer:
cluster peer create -peer-addrs 10.0.0.11,10.0.0.12
cluster peer show          # expect Available/Available
cluster peering policy show

2. Create the destination volume

volume create -vserver svm2 -volume vol1_dst -aggregate aggr2_node1 \
    -size 500GB -type DP -language <match source>
# Language must match the source or initialize fails with a
# language mismatch error.

3. Create and initialize the relationship

snapmirror create -source-cluster cluster-01 -source-vserver svm1 \
    -source-volume vol1 -destination-cluster cluster-02 \
    -destination-vserver svm2 -destination-volume vol1_dst \
    -type XDP -policy MirrorAllSnapshots -schedule 15min-cron
snapmirror initialize -destination-path svm2:vol1_dst
snapmirror show -destination-path svm2:vol1_dst

Full SVM DR uses vserver endpoints instead of volumes — see SVM disaster recovery. To replicate into FabricPool-capable tiers or between cloud ONTAP instances, the same commands apply; only peering endpoints differ.

Fan-out, cascading & version-flexible replication

• Fan-out (one source, many destinations): supported for XDP. Each destination pulls independently; label-based rules let you send hourly snapshots to a local HA mirror and nightly vaults to a StorageGRID-backed FabricPool backup destination.
• Cascading (A→B→C): B is simultaneously a destination and a source. Requires version-flexible replication when A and C run different ONTAP versions: the intermediate converts snapshots to a version-independent format.
• Version-flexible also protects mixed-version estates during rolling upgrades — but its conversions add CPU on the intermediate node and it cannot replicate while a conversion is pending.

# Cascade: on cluster-02, create A->B first, then B->C
snapmirror create -source-path svm2:vol1_dst \
    -destination-path svm3:vol1_c -type XDP \
    -policy MirrorAndVault -schedule daily-cron
snapmirror initialize -destination-path svm3:vol1_c

Monitoring: lag, history & transfer stats

snapmirror show -fields lag-time,last-transfer-size,\
last-transfer-duration,last-transfer-error,health-status

# Enumerate transfers with errors first
snapmirror show-history -fields status,end-time,error

# Per-relationship throughput right now
snapmirror show -destination-path svm2:vol1_dst -instance

# EMS events for replication failures
event log show -message-name *Snapmirror*

Healthy relationships report lag-time under roughly 1.5× the schedule interval. Route persistent laggards into alerting via Active IQ UM or SNMP/EMS forwarding; snapmirror.config.replication.failed and wafl.snap.delete pressure are the usual early signals.

Resync, rollback & disaster recovery

Planned failover (source intact)

snapmirror quiesce  -destination-path svm2:vol1_dst
snapmirror update   -destination-path svm2:vol1_dst   # drain final delta
snapmirror break    -destination-path svm2:vol1_dst   # dest becomes RW

Fail back (reverse resync)

snapmirror resync -source-path svm2:vol1_dst \
    -destination-path svm1:vol1    # fast re-reverse; no new baseline
# then when ready, break back to the original direction

Disaster recovery (source destroyed)

snapmirror break -destination-path svm2:vol1_dst -force
# serve clients from svm2:vol1_dst; rebuild the source cluster later, then:
snapmirror resync -source-path svm2:vol1_dst -destination-path svm1:vol1_rebuilt

Rollback to an older snapshot

snapmirror restore pulls a selected snapshot back over an existing relationship without a new baseline:

snapmirror restore -source-path svm1:vol1 \
    -destination-path svm2:vol1_dst \
    -source-snapshot nightly.3   # 3-day-old recovery point

SnapMirror break preserves destination snapshots; resync after a break needs at least one common snapshot — if the destination was written to and snapshots diverged completely, only a full re-baseline remains. For in-sync zero-RPO pairs, use SnapMirror Active Sync instead; for moving volumes permanently, use volume move.

Troubleshooting matrix

FAQ

SnapMirror vs SnapVault — what's actually different?

Engine-wise they're the same replication machinery. SnapMirror relationships (type async-mirror) mirror all labeled snapshots for fast failover; SnapVault (type vault) keeps longer retention for backup. One policy can combine both — the MirrorAndVault pattern — which is the recommended architecture for 3-2-1 designs (see backup & restore).

Does SnapMirror replicate over the cluster interconnect?

No. It uses intercluster LIFs — dedicated LIFs on data ports in an intercluster IPspace or broadcast domain. Peering validates connectivity, but the transfer rides the intercluster network (ports 11104/11105, see network ports reference).

Can I change the schedule without re-baselining?

Yes. snapmirror modify -schedule (or -policy) takes effect on the next evaluation; data already replicated stays common. Only changing the relationship type or breaking common-snapshot lineage forces a baseline.

How much destination space does SnapMirror need?

Plan destination size = source used space + room for the retained snapshot deltas on the destination's own schedule. A mirrored volume with 30 daily keeps typically needs 15–30% more than source used, depending on churn. See capacity planning and storage efficiency — dedupe/compression savings replicate to XDP destinations.