Data Protection

Start with RPO/RTO

• RPO (Recovery Point Objective) — how much data you can afford to lose (time-based).
• RTO (Recovery Time Objective) — how fast you must be back.
• RPO 0 needs synchronous replication (SnapMirror Synchronous, SM-BC, MetroCluster). RPO minutes-to-hours needs scheduled async SnapMirror. Point-in-time recovery needs snapshots/backups (SnapVault, NDMP).
• The 3-2-1 rule still applies: 3 copies, 2 media, 1 offsite. ONTAP gives you the onsite copies and SnapMirror gives you the offsite one.

Snapshots

• Copy-on-write point-in-time images; near-free until blocks change. Basis of everything else in this page.
• Snapshot policies define schedules + retention (e.g., hourly × 24, daily × 7, weekly × 4). Created automatically per policy; manual snapshots possible.
• Snapshot reserve (default 5%) protects snapshot space.
• snapshot restore rolls a volume back; for files, clients can browse .snapshot (if enabled).

SnapMirror

SnapMirror replicates snapshots from a source volume to a destination volume — not a byte stream. This is why it's efficient, why lag is measured in "how stale is the last replicated snapshot," and why the destination is read-only (until you break the relationship).

• Async SnapMirror (XDP — extended data protection) — scheduled (hourly/daily/weekly) or manual. Types: DP (data protection), XDP. Fan-in/fan-out topologies allowed (one source → many destinations).
• SnapMirror Synchronous (SM-S) — writes are acknowledged when written to both source and destination. Modes: Sync (ack when both) and StrictSync (fail writes if the destination can't keep up — used for zero RPO with strict consistency). Introduced ~ONTAP 9.3. (Verify version.)
• SnapMirror Business Continuity (SM-BC) — ONTAP 9.10+, requires ONTAP One licensing. Synchronous replication with automatic failover (storage-side) for iSCSI/FC and NAS. RPO 0 with minimal RTO — the "no storage touch" DR answer for SAN/NAS.
• SnapMirror S3 — replicate snapshots to an S3 object store (ONTAP 9.6+), including cloud object storage — cheap long-term archive.
• Relationship states: Snapmirrored (healthy), Uninitialized (need snapmirror initialize), Broken-off (after snapmirror break — destination becomes writable), Resyncing (after snapmirror resync).
• Peering first: cluster peering (intercluster LIFs, port 10000) then SVM peering, then SnapMirror relationships.

# Peering (once per pair of clusters)
cluster peer create -peer-cluster clusterB -peer-intercluster-lifs 10.1.1.10,10.1.1.11
vserver peer create -vserver vs1 -peer-vserver vsB -peer-cluster clusterB
# Async SnapMirror relationship
snapmirror create -source-path vs1:vol1 -destination-path vsB:volB -type XDP -policy DPDefault -schedule hourly
snapmirror initialize -destination-path vsB:volB
# Check health / lag
snapmirror show -fields state,status,lag-time,last-transfer-end
snapmirror show -destination-path vsB:volB -detail
# Manual update, break, resync, restore
snapmirror update -destination-path vsB:volB
snapmirror break -destination-path vsB:volB
snapmirror resync -destination-path vsB:volB
snapmirror restore -source-path vsB:volB -destination-path vs1:vol1

SnapVault (now SnapMirror vault)

• Disk-to-disk backup with long retention — originally SnapVault, delivered through SnapMirror since ONTAP 9.4 ("SnapMirror with vault" / vault labels).
• Vault policies use labels (e.g., daily, weekly) to match source snapshots and define how long each label is kept on the destination — enabling "keep 5 years of monthlies" without keeping everything.
• Unlike plain SnapMirror, vault keeps many generations per policy on the destination.

MetroCluster

• Synchronous, block-level mirroring of aggregates (via SyncMirror) between two sites — RPO 0 at the storage layer. Two nodes per site, stretched HA pairs.
• Transport: FC (traditional) or IP (ONTAP 9.7+). IP MetroCluster uses an external Mediator for automatic failover decisions.
• Disaster recovery ops: metrocluster switchover (site fails → surviving site serves) and metrocluster switchback (return).
• Use case: campus/metro distances with zero RPO and automatic failover, when SM-BC's volume-level granularity isn't enough (MetroCluster mirrors everything).

Full MetroCluster fundamentals guide (FC vs IP, mediator, switchover/switchback workflow) →

NDMP

• Dump-based backup protocol (tape or disk), driven by backup software (NetBackup, etc.).
• Local (dump to local tape) or 3-way (NDMP source → NDMP tape server).
• Note: NDMP backup of a SnapMirror destination volume is not supported — back up sources (or use SnapVault/SnapMirror S3 instead).
• Generally being replaced by snapshot-based workflows (SnapCenter, SnapMirror S3, snapshots themselves).

Compliance & ransomware

• SnapLock — WORM (write-once-read-many) volumes for compliance/retention. Compliance mode (regulatory, can't be disabled) vs Enterprise mode (company policy, privileged deletion with approval).
• Ransomware protection — ONTAP 9.10+ adds volume-level snapshot-based protection: automatic frequent snapshots, suspicious-activity detection (with AI via Active IQ/BlueXP), and immutable snapshots to resist deletion. Combined with SnapLock for tamper-proof retention.
• SnapCenter — NetApp's application-consistent backup/restore product (SQL, Oracle, Exchange, SAP, file servers) — snapshots + logs for DB consistency, restores into place.

Exam traps to know

• SnapMirror replicates snapshots, so the destination's content is as old as the last transferred snapshot (lag). It is not a continuous byte mirror (except SM-S/SM-BC).
• Destination volumes are read-only until you break the relationship.
• RPO 0 requires sync replication; snapshots alone can't give RPO 0 (they're periodic).
• Vault ≠ mirror: vault keeps many labeled generations for retention; mirror keeps the replication schedule's snapshots.
• MetroCluster mirrors aggregates (whole systems); SM-BC mirrors volumes with automatic failover; plain SnapMirror is manual-failover volume replication.
• Peering order: cluster peer → SVM peer → SnapMirror relationship.
• SnapVault labels (daily/weekly…) are what match source snapshots to destination retention.

Next: Storage efficiency →