Data Protection and SnapMirror Replication
What this domain tests
Questions test Snapshot policy mechanics and the SnapMirror lifecycle: initialize, update, break, resync, and the difference between mirroring and vaulting.
Core rules
- A Snapshot policy is a set of schedules plus a count; each copy gets a label such as
hourly,daily, orweekly. SnapMirror policies select which labels replicate. - Relationship types include DP (data protection), XDP (extended, used for vaulting and unified replication), and TDP (transitional).
- Async SnapMirror transfers only new Snapshot copies since the last transfer; SnapMirror Synchronous and SnapMirror Business Continuity require a mediator for automatic failover.
- Cluster peering and SVM peering are prerequisites, and intercluster LIFs carry replication traffic between clusters.
- SVM DR replicates an entire SVM, including configuration such as shares and export policies, with identity preserve so clients keep working after failover.
Worked example
A volume relationship shows lag-time climbing. Run snapmirror show -fields status,health,lag-time to confirm the state is Transferring and not Idle. If the mirror policy is MirrorLatest, only the newest common Snapshot label is replicated, so a missing label on the source stops progress. Create or correct the Snapshot policy, then snapmirror update to catch up rather than reinitializing.
Traps
Running snapmirror resync when you should be running snapmirror update - resync is for re-establishing a broken relationship. Assuming snapmirror break deletes the destination. Forgetting that a broken destination becomes writable and therefore must be resynced before reuse as a mirror.