NetApp ONTAP SnapMirror: Break, Resync and Policies

SnapMirror relationships are easy to create and easy to break badly. The two operations that decide whether a DR test goes smoothly are snapmirror break (make the destination writable so it can serve data) and snapmirror resync (turn it back into a mirror). Do them in the wrong order, or resync when the source and destination no longer share a common Snapshot copy, and the relationship has to be re-initialised from scratch. This article covers the policy choices, the lifecycle commands, and the checks that keep a DR test reversible.

Pick the right policy first

• MirrorAllSnapshots / MirrorLatest – asynchronous mirror of snapshots only. Recovery point matches the snapshot schedule; the destination is a copy of the source's snapshot timeline.
• mirror_vault – mirrors snapshots and then vaults (retains) them for the longer retention you specify in the policy rules. This is the common "backup to a second site" choice.
• mirror_and_vault (unified) – a mirror copy for fast failover plus a vaulted copy for retention.
• Sync / strict-sync – synchronous replication for RPO zero, needs a low-latency link and a separate policy type.

cluster1::> snapmirror policy show -policy MirrorAllSnapshots -instance
cluster1::> snapmirror policy create -policy SM_MirrorVault -type mirror-vault
cluster1::> snapmirror policy add-rule -policy SM_MirrorVault -vserver svm1 -rule "daily" -snapmirror-label daily -keep 30

Creating and initialising a relationship

cluster2::> snapmirror create -source-path svm1:vol_src -destination-path svm2:vol_dst_mirror -type XDP -policy MirrorAllSnapshots
cluster2::> snapmirror initialize -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror show -fields state,status,lag-time,health

Use -type XDP for volume relationships (SnapVault/XDP technology) and the cluster peering + SVM peering interfaces must exist before the create step. Lag time, not just state, is what you watch in operations: a relationship can be "Snapmirrored" while an hour behind.

Routine operations

cluster2::> snapmirror update -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror quiesce -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror resume -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror abort -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror show-history -destination-path svm2:vol_dst_mirror

Breaking for a DR test

cluster2::> snapmirror quiesce -destination-path svm2:vol_dst_mirror
cluster2::> snapmirror break -destination-path svm2:vol_dst_mirror
cluster2::> volume show -vserver svm2 -volume vol_dst_mirror -fields state,type

After the break the destination volume is writable and can be mounted, joined to a test AD, or restored into a lab. Two rules matter here: the destination volume type changes to rw, and any new writes on the destination are invisible to the source when you resync unless a common snapshot still exists. For a test, write as little as possible and keep the original snapshots intact.

Resyncing correctly

cluster2::> snapmirror resync -destination-path svm2:vol_dst_mirror -preserve false
cluster2::> snapmirror show -destination-path svm2:vol_dst_mirror -instance

Resync finds a common Snapshot copy between source and destination and re-establishes the relationship incrementally. If the relationship has no common Snapshot (destination too far diverged, snapshots deleted, or a new volume with the same name), the command fails and the only path is snapmirror delete followed by snapmirror create and a fresh snapmirror initialize. -preserve false drops local snapshots taken after the break, which is normally what you want after a DR test so the mirror matches the source exactly.

SVM-level replication

cluster2::> snapmirror promote -destination-path svm2:svm_dr
cluster2::> snapmirror show -fields state,source-path,destination-path

For SVM DR (vserver replication) the roles are switched with snapmirror promote: the DR SVM becomes the active one and the original source, if it comes back, must be resynced from the new primary. Treat promote as a one-way decision and document the failback procedure before a failover, not during it.

Checks before and after every operation

• Confirm free space on the destination aggregate – mirror operations fail cleanly but leave the relationship behind.
• Verify the policy retention rules still satisfy the business RPO/RTO; a mirror-only policy retains nothing beyond the snapshot timeline.
• Record snapmirror show output before a DR test so you can prove the state afterwards.
• Alert on lag-time thresholds and on health status, not only on state.

Related: ONTAP snapshot policies, ONTAP volume move and cutover, and FlexGroup create and expand.

原文链接：https://docs.netapp.com/us-en/ontap-cli/snapmirror-break.html