ONTAP disaster recovery strategy comparison

Start with the business promise: how much data may be lost, how long service may be unavailable, which failures count, and who can declare a disaster. Technology selection follows those answers.

RPO and RTO spectrum from MetroCluster through synchronous and asynchronous replication to vault retention

Define the decision space

RPO is the acceptable data-loss window; RTO is the acceptable recovery-time window. Add distance and latency, budget, data change rate, bandwidth, application consistency, dependency order, cyber-recovery needs, and the staffing available at 03:00. “Zero RPO” describes committed replicated writes; it does not mean every application dependency is instantly usable.

One comparison, different jobs

Technology	Mechanism	RPO	RTO	Distance	Failover	Failback effort	Best fit
MetroCluster FC/IP	Synchronous mirrored aggregates plus stretched cluster	0 for protected writes	Low; design-dependent	Campus/two-site; platform and latency limits apply	Planned switchover; automatic unplanned switchover in supported Mediator designs	Heal, switchback, validate	Site resilience with storage identity continuity
SnapMirror Sync	Synchronous volume replication over IP	0 in sync	Manual activation	Network-latency constrained; cross-region only when limits are met	Manual break/host orchestration	Resync/reverse path	Zero data loss where automated active access is unnecessary
SnapMirror Async	Snapshot-based scheduled replication	Schedule plus transfer lag; often 15 minutes or more	Minutes to hours	IP/WAN, broadly flexible	Manual or externally orchestrated	Reverse resync and planned cutback	Cost-effective regional DR
SVM DR	Replicates an SVM namespace, volumes and supported configuration	Schedule/lag	Runbook-dependent	Intercluster IP	Manual/orchestrated activation	Reverse relationship and identity checks	Whole-SVM recovery
SnapMirror Active Sync / SM-BC	Synchronous consistency-group replication with host multipathing and Mediator	0 when in sync	Near-zero/zero storage interruption in supported topology	Metro/latency constrained	Automated storage failover for supported failures	Resync and preferred-site restoration	Tier-1 active-active SAN; NAS support depends on release
SnapVault policy	SnapMirror vault policy retains destination snapshots	Backup schedule	Restore-dependent	Local or remote IP	None	Restore/reprotect	Long retention and archive
SnapCenter backups	Application plug-ins coordinate consistent snapshots and secondary copies	Policy schedule	Application restore-dependent	Follows storage targets	Application workflow, not site failover	Restore/reprotect	Oracle, SQL, VMware and other app-consistent recovery

Exact RPO/RTO, distance, protocol, and automation support depend on ONTAP, platform, Mediator, application, and topology. Check the current Interoperability Matrix and product limits.

Which one when?

Downtime budget: if seconds are unacceptable, evaluate MetroCluster or active sync; otherwise start with SVM/volume DR.
Distance: if synchronous latency limits cannot be met, use asynchronous replication.
Data-loss tolerance: zero pushes toward synchronous; minutes permit async; long-term recovery needs vault retention too.
Automation: decide whether storage, hosts, networks, DNS, databases, and people can all fail over safely. Storage automation alone is not an application runbook.

Layer protection

A MetroCluster can protect the primary service from a site outage while asynchronous SnapMirror sends another copy to a distant failure domain. Add app-consistent SnapCenter retention and an immutable or isolated backup tier for cyber recovery. Each layer should address a different failure; duplicating the same administrative and network boundary is not independence.

cluster::> snapmirror show -fields relationship-type,policy,state,status,lag-time,last-transfer-end-timestamp
source-path destination-path type policy state status lag-time last-transfer-end-timestamp
prod:db     dr:db_dp         XDP  MirrorAndVault Snapmirrored Idle 00:16:42 8/27/2026 14:00:11

Test without improvising on production

A normal SVM DR initialization uses -vserver-dr-protection when creating the destination SVM; the flag is not an option to snapmirror initialize. Keep the DR relationship intact and rehearse through a supported isolated clone or designated test destination. Network test LIFs, DNS, credentials, routing, application startup order, and cleanup must be scripted.

dr::> vserver create -vserver finance_dr -subtype dp-destination -vserver-dr-protection protected
dr::> snapmirror create -source-path prod:finance -destination-path dr:finance_dr: -type XDP -policy MirrorAllSnapshots
dr::> snapmirror initialize -destination-path dr:finance_dr:
Operation is queued: snapmirror initialize of destination "dr:finance_dr:".

# Clone-based rehearsal from a replicated recovery snapshot
dr::> volume clone create -vserver test_svm -flexclone finance_test -type RW -parent-vserver dr_svm -parent-volume finance_dp -parent-snapshot nightly.2026-08-27_0000
[Job 9912] Job succeeded: Successful

Failover and failback sketches

Async / SVM DR

Confirm scope → stop/quiesce source if reachable → update final delta → quiesce → break → activate LIFs/hosts/apps → validate. For failback, stop apps, replicate the delta back with resync/reverse resync, activate original, and reprotect.

SnapMirror Sync

Confirm relationship state and write policy → coordinate hosts → break destination → bring services online. Re-establish synchronization only after declaring the authoritative copy.

MetroCluster

Use metrocluster operation show, validate, switchover, heal aggregates/root, then switchback when the failed site is healthy. Follow the model-specific procedure.

Active Sync

Verify consistency-group and Mediator health plus host paths. Planned failover is preferred; after an outage, confirm the surviving copy and resynchronize before restoring preferred-site placement.

dr::> snapmirror quiesce -destination-path dr:db_dp
dr::> snapmirror break -destination-path dr:db_dp
Operation succeeded: snapmirror break for destination "dr:db_dp".

siteA::> metrocluster check run
siteA::> metrocluster check show
Component           Result
nodes               ok
config-replication  ok
aggregates          ok

Monitor health and common failures

Signal	Likely cause	Response
Lag grows every interval	Change rate exceeds bandwidth, transfer errors, or schedule overlap	Inspect transfer errors, network and baseline sizing; do not merely shorten schedule.
Expected recovery point missing	Source snapshot policy/labels do not match vault rules	Compare policy rules and snapshot labels.
Relationship broken after DR	Break was activation, not reprotection	Choose authoritative side, resync carefully, then restore monitoring.
“Healthy” storage, failed app	DNS, identity, host paths, certificates, or startup order omitted	Expand the test to the complete service.

cluster::> snapmirror show -destination-path dr:db_dp -instance
Relationship Status: Idle
Relationship State: Snapmirrored
Lag Time: 00:16:42
Last Transfer Error: -
cluster::> snapmirror show -fields state,status,lag-time,last-transfer-end-timestamp