SVM DR Guide: Setup, Failover & Failback

What SVM DR Is (and When to Choose It)

SVM DR is a SnapMirror relationship where the unit of protection is the whole data-serving SVM rather than individual volumes. On the destination you get a dp-destination copy of the source SVM holding its NFS exports, SMB shares, name-service (DNS/LDAP/NIS) settings, RBAC, quotas, QoS policies, snapshots, and the data itself. Because clients reconnect with the same names and paths (when using -identity-preserve true) or a re-IP step (-discard-configs network), recovery is much faster than rebuilding config by hand.

Position it against the alternatives:

Relationship types supported: SnapMirror DR (async-mirror policy type, default policy MirrorAllSnapshots) and unified replication (mirror-vault type, default MirrorAndVault) which adds long-term retention on the destination.

The mirror-vault behavior change (ONTAP 9.9.1+)

With a mirror-vault policy on ONTAP 9.9.1 or later, destination snapshots are preserved independently of the source: they are not overwritten during scheduled updates or resync, are not deleted on break or flip-resync operations, and neither user-defined nor system-defined snapshot policies are copied from source to destination. This lets the DR side keep its own retention plan instead of mirroring the primary's.

What Gets Replicated: identity-preserve Decides

The snapmirror create flag -identity-preserve is the single most consequential choice:

• true — replicates the entire SVM configuration (LIFs, Kerberos on LIFs, routes, SMB server security, export policies, DNS, LDAP, NIS, SSL certificates, SNMP users, and more). This is the standard choice for true DR. Only one -identity-preserve true relationship is allowed per source SVM by default.
• false — replicates only volumes plus authentication/authorization configuration and the limited protocol/name-service subset (local groups/users, home directories, symlink mapping, Fpolicy, audit, UNIX users/groups, quota policies). LIFs, routes, DNS/LDAP servers, export rules etc. must be recreated manually on the destination.

Frequently missed rows of the replication matrix:

Practical consequence: SVM DR is primarily a NAS DR solution. If your SVM serves LUNs, plan separate automation to recreate igroups, portsets, and SAN LIFs on the destination before hosts can map.

Requirements & Hard Limits

• Peering first: cluster peering between the two clusters and SVM intercluster peer relationship between the source and destination SVMs are prerequisites.
• Same ONTAP version: version-independence is not supported for SVM replication — destination cluster must run the same ONTAP version as the source to support failover/failback cleanly. Plan upgrades as paired operations.
• Intercluster only: source and destination SVMs cannot live on the same cluster.
• RPO floors: minimum schedule is 15 minutes for FlexVol volumes, 30 minutes for FlexGroup volumes in an SVM relationship.
• Scale ceilings: up to 300 flexible volumes per SVM, 1,000 per HA pair, and a recommended maximum of 128 SVM DR relationships per cluster (platform-dependent — confirm in Hardware Universe).
• Fan-out: single source may replicate to at most two destinations (since 9.4).
• FabricPool: supported since 9.6; volumes need not be on FabricPool aggregates but tiering policies must match. FabricPool + FlexGroup + SVM DR together requires 9.12.1+.
• Autonomous Ransomware Protection: supported with SVM DR since 9.12.1.
• Consistency Groups: with CGs present, a maximum of 32 SVM DR relationships is supported (9.14.1+).
• IPsec: enabling IPsec on SVMs configured for SVM DR is not supported beginning with ONTAP 9.19.1 — disable it or pick another SVM.
• Not supported alongside: SnapMirror Synchronous, SnapMirror Cloud, and ONTAP S3.
• MetroCluster: an active SVM in a MetroCluster configuration can be an SVM DR source since 9.5; the sync-source's relationship info replicates to the MMC partner. MetroCluster as a destination has version-specific restrictions (treat as migration-only in 9.10.1+, see TR-4966).

Step-by-Step: Create SVM DR (CLI)

All steps are run from the destination unless noted. Worked example: source svm1, destination svm_backup.

1. Peer the clusters and SVMs

# On both clusters (details in our cluster peering guide):
cluster_dst::> cluster peer create -generate-outputs
cluster_src::> cluster peer create -peer-addrs <dst_intercluster_LIFs>

# SVM intercluster peer relationship
cluster_dst::> vserver peer create -vserver svm_backup -peer-vserver svm1 -peer-cluster cluster_src -applications snapmirror

2. Create the dp-destination SVM

cluster_dst::> vserver create -vserver svm_backup -subtype dp-destination

The SVM name must be unique across both clusters (same data-protection namespace for peered SVMs).

3. Create a schedule honoring the RPO floor

# Saturdays at 03:00 example — for real DR use ≥ every 15 min (FlexVol)
cluster_dst::> job schedule cron create -name my_weekly -dayofweek saturday -hour 3 -minute 0

4. Create the relationship with identity preserve

cluster_dst::> snapmirror create \
    -source-path svm1: -destination-path svm_backup: \
    -type XDP -schedule my_daily \
    -policy MirrorAllSnapshots -identity-preserve true

Always include the colon after the SVM name — svm1: means "the whole SVM", while svm1:vol1 would create a plain volume relationship instead. For unified replication substitute -policy MirrorAndVault (or your custom mirror-vault policy).

5. Stop the destination SVM, then initialize

cluster_dst::> vserver stop -vserver svm_backup
cluster_dst::> snapmirror initialize -source-path svm1: -destination-path svm_backup:
# Monitor until baseline completes:
cluster_dst::> snapmirror show -destination-path svm_backup:

System Manager path (9.8+): Protection → Relationships → Protect → Storage VMs (DR); pick the policy, source SVM, and either reuse or rename the destination SVM.

Tailoring Scope: Excluding Networks or Volumes

Different subnets? discard LIFs from replication

If source and destination sites use different IP addressing, replicate with LIFs excluded rather than letting stale addresses land on the DR site:

cluster_dst::> snapmirror policy create -vserver svm_backup -policy dr_no_net \
    -type async-mirror -discard-configs network
cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: \
    -type XDP -schedule my_15min -policy dr_no_net -identity-preserve true

-identity-preserve true is required when using -discard-configs network. You then assign fresh LIFs on the destination before serving data.

Keep a volume out of DR entirely

cluster_src::> volume modify -vserver svm1 -volume vol_scratch -vserver-dr-protection unprotected

Useful for scratch/staging volumes whose contents don't justify baseline transfer and update traffic.

Runbook A: Activate the Destination After a Disaster

Activation = stop transfers, break the relationship, swap which SVM is running. From the destination cluster:

# 1. Stop scheduled transfers
cluster_dst::> snapmirror quiesce -source-path svm1: -destination-path svm_backup:

# 2. Abort any in-flight transfer
cluster_dst::> snapmirror abort -source-path svm1: -destination-path svm_backup:

# 3. Break the relationship — destination volumes become writable
cluster_dst::> snapmirror break -source-path svm1: -destination-path svm_backup:

# 4. If identity-preserve was true: STOP THE SOURCE SVM
#    (two identity-preserving SVMs online simultaneously = config conflict)
cluster_src::> vserver stop -vserver svm1

# 5. Start the destination
cluster_dst::> vserver start -vserver svm_backup

In a true outage step 4 is simply unreachable — proceed without it, and expect the last common snapshot to define your actual RPO. Verify client-facing state afterwards:

cluster_dst::> vserver show -vserver svm_backup
cluster_dst::> network interface show -vserver svm_backup
cluster_dst::> volume show -vserver svm_backup

Runbook B: Fail Back with Reverse Resync

Once the original source site is healthy, move production back. This reverses roles: the failed-over destination becomes the temporary source. Requires the original source's baseline to be intact — otherwise re-initialize first. Pause client writes early; resumed writes to the wrong side will fork your data.

1. Create the reversed relationship (on the original source cluster, same policy and identity-preserve setting):
   cluster_src::> snapmirror create -source-path svm_backup: -destination-path svm1:
2. Resync into the original source — no baseline transfer, but can be slow; consider off-hours:
   cluster_src::> snapmirror resync -source-path svm_backup: -destination-path svm1:
   ONTAP 9.11.1+: add -quick-resync true to skip warehouse rebuild/restore and shorten rehearsals — trade-off: destination storage efficiency is not preserved and space usage may grow.
3. Cut over: stop the currently-serving SVM and disconnect its clients:
   cluster_dst::> vserver stop -vserver svm_backup, confirm with vserver show (state must read stopped).
4. Final delta from temporary source to original source:
   cluster_src::> snapmirror update -source-path svm_backup: -destination-path svm1:
5. Quiesce and break the reversed relationship:
   cluster_src::> snapmirror quiesce -source-path svm_backup: -destination-path svm1:
cluster_src::> snapmirror break -source-path svm_backup: -destination-path svm1: (run once status shows Quiesced).
6. Start the original source SVM: cluster_src::> vserver start -vserver svm1
7. Restore protection forward (from the original destination):
   cluster_dst::> snapmirror resync -source-path svm1: -destination-path svm_backup:
8. Clean up the scaffolding: delete the reversed relationship from the source side (snapmirror delete -source-path svm_backup: -destination-path svm1:) and release it from the destination side (snapmirror release -source-path svm_backup: -destination-path svm1:). Resume client writes against svm1.

If resync fails with "no common snapshot", the baseline chain is gone — fall back to snapmirror initialize on the reversed pairing (full baseline transfer) instead of forcing resync.

Monitoring Health

# Relationship health, lag, and last transfer result
cluster_dst::> snapmirror show -instance

# One-line fleet view (all SVM-type relationships)
cluster_dst::> snapmirror show -relationship-type "extended_data_protection"

# Confirm schedules exist and match intended RPO
cluster_dst::> job schedule cron show

# Check the dp-destination hasn't been started accidentally
cluster_dst::> vserver show -subtype dp-destination

Alert-worthy states: Status other than Idle persisting past your transfer window, growing New Data/lag numbers after every update, repeated Last Transfer Error entries, and a destination SVM left running outside a declared drill or cutover.

Common Traps & Troubleshooting

Rehearsal Checklist (Do Quarterly)

• Document expected RPO from current schedule; compare measured lag during the drill window.
• Verify DNS/LDAP reachability from the DR site — replicated config needs reachable services to authenticate clients.
• Confirm vserver stop/start works non-interactively and account permissions allow each runbook command.
• Practice fail-back with -quick-resync true (9.11.1+) and watch destination space growth if efficiency matters.
• Check FabricPool tiering parity and object-store reachability from the DR site if tiering is in play.

Related Pages

• Cluster & SVM Peering Architecture — prerequisite plumbing for any SVM DR build.
• SnapMirror Active Sync & SM-BC — when zero-RPO synchronous beats asynchronous SVM DR.
• Troubleshooting SnapMirror — transfer errors, lag diagnosis.
• Ransomware Protection — ARP pairs with SVM DR since 9.12.1.