SnapMirror Lag Exceeds RPO on a Daily Snapshot Policy
Cluster PROD (ONTAP 9.12.1) protects the 4 TB volume vol_ora to cluster DR with a SnapMirror asynchronous relationship using the default Asynchronous (MirrorLatest) policy. vol_ora uses a custom Snapshot policy named daily_only: one Snapshot copy at 00:00 with retention of 7. A manual transfer completes in about six minutes. snapmirror show reports Healthy, last transfer ending at 00:06, and a lag time that climbs close to 24 hours before resetting. The stated RPO is four hours. The DR aggregate has 22% free space. A SnapVault relationship also protects the DR copy of vol_ora to a third site. Application owners are asking why the mirror is 'always 20 hours behind' when the network is clearly fast enough.
1. Explain why lag approaches 24 hours when a transfer takes six minutes, name the commands that confirm it, and describe the least-disruptive fix that meets a four-hour RPO.
Read the worked answer
With MirrorLatest, SnapMirror transfers the newest common Snapshot copy, and lag is measured from that copy to now. If the source creates copies only at 00:00, the newest copy is up to a day old, so the effective RPO equals the Snapshot interval, not the transfer duration. Confirm with snapshot policy show -volume vol_ora, snapshot show -volume vol_ora, snapmirror policy show -policy Asynchronous and snapmirror show -fields lag-time,last-transfer-end-timestamp. Fix: create an hourly policy (for example 12 hourly plus 7 daily, tuned to the business), attach it with volume modify -vserver svm_prod -volume vol_ora -snapshot-policy ora_hourly, then let the next scheduled update pick up a newer copy or run one snapmirror update. Before doing this, check aggregate and Snapshot reserve headroom, because more frequent copies change both source space consumption and which copies the vault policy can select.
2. For the SnapVault relationship to the third site, which Snapshot copies are transferred and what governs retention there?
Read the worked answer
A version-flexible (vault) relationship runs on its own schedule and selects copies from the DR volume by SnapMirror label. Labels originate in the source Snapshot policy rules on PROD and are carried across the mirror, so a copy labelled 'hourly' on vol_ora is what a vault rule with snapmirror-label hourly will pick up. Retention on the third site is independent of source retention: snapmirror policy show -policy <vault-policy> -instance lists each rule's label, count and cron schedule, and those counts define how many copies stay on the vault volume. Verify the flow with snapmirror list-destinations on DR and snapshot show -snapmirror-label on the vault copy. The risk to flag: shortening source retention can remove the only labelled copies before the vault transfer runs, creating gaps that are invisible until a restore is attempted.
3. A false alarm led the DR team to run snapmirror break on the DR volume and serve writes for 30 minutes while PROD kept accepting writes. What are the options to restore protection, and what data loss must be documented?
Read the worked answer
After the break, both copies diverged. Try snapmirror resync -source-path svm_prod:vol_ora -destination-path svm_dr:vol_ora_mirror first: resync uses the destination's current content as a new base and transfers only differences, so DR-side writes can survive. It fails when there is no usable common Snapshot or when ONTAP cannot reconcile the divergence ('no common Snapshot'); then snapmirror initialize is required, which overwrites the DR volume with a full baseline and discards the 30 minutes of DR writes. Before either step, confirm versions, time sync, and that the relationship is not still in an active transfer. After it completes, check snapmirror show -fields status,mirror-state,healthy. Document the gap explicitly: DR writes accepted during the 30 minutes are lost unless exported or copied, and PROD writes after the break are unprotected until resync finishes.