Home / Troubleshooting / SnapMirror Problems

SnapMirror Problems

Symptoms: lag keeps growing, transfers fail, the relationship is stuck in an odd state, or failover to the destination doesn't work the way you expected.

1. Understand the states first

State	Meaning
`Snapmirrored`	Healthy — replicating on schedule
`Uninitialized`	Relationship created but never initialized — run `snapmirror initialize`
`Broken-off`	Destination was `break`n — it is now read-write and no longer receiving updates
`Resyncing`	Recovering after `resync` — the destination is being brought back in sync (may take a while)
`Failed` / transfer errors	Last transfer failed — investigate (below)

# The two commands that tell you 90% of the story
snapmirror show
snapmirror show -destination-path vsB:volB -detail
# Lag and last transfer
snapmirror show -fields destination-path,state,status,lag-time,last-transfer-end,last-transfer-size

2. Lag growing / never catching up

Lag = how stale the destination is. If it grows continuously:

Change rate exceeds transfer rate. The source is generating more changed data per interval than can be shipped. Options: reduce snapshot frequency (fewer, larger transfers can be more efficient), increase network bandwidth, enable compression on the relationship (snapmirror modify -compress true — available where supported), or use SnapMirror S3 for less time-critical copies.
Network bottleneck. Check intercluster LIF throughput: network interface show -role intercluster, port errors: network port show -fields link,error-*. Test with the catch-up estimator to see if your link can even theoretically keep up.
Source volume busy. SnapMirror competes with production I/O. QoS on the source or scheduling transfers off-peak helps.

# Force an update and watch it
snapmirror update -destination-path vsB:volB
snapmirror show -destination-path vsB:volB -detail   # watch last-transfer-size and time

3. Transfer failures

snapmirror show -detail prints the last transfer error. Common ones:

Error	Typical cause / fix
Peer unreachable / connection failed	Cluster or SVM peering broken; intercluster LIFs down; firewall blocking port 10000. Verify: `cluster peer show`, `vserver peer show`, `network ping-lif`
Destination volume full	The destination volume (or its aggregate) lacks space for the next snapshot. Grow it or free space; thin provisioning recommended on destinations
Snapshot not found on source	A snapshot the relationship needed was deleted before transfer (e.g., autodelete ate it). Re-run `snapmirror update` to resync from the latest common snapshot, or `snapmirror resync`
Authentication/peering failure	Peering passphrase mismatch or SVM peer deleted. Re-establish `cluster peer`/`vserver peer`
Destination read-only mismatch	The destination volume was modified (e.g., someone wrote to it after break). Re-create the relationship if the destination data is disposable

4. Breaking and restoring

To fail over to the destination (DR), you break the relationship — the destination becomes writable:

# Fail over: make the destination writable
snapmirror break -destination-path vsB:volB
# (applications now use the former destination)

To return after the source is healthy, re-establish and resync — this brings the old source back in sync from the destination without a full reseed (it only ships changes since the common snapshot):

# From the (former) destination cluster: re-establish toward the original source
snapmirror resync -destination-path vs1:vol1
# Wait for state to become Snapmirrored, then optionally switch direction back
snapmirror show -fields state,status,lag-time

Watch the direction In snapmirror resync -destination-path vs1:vol1, the destination is the volume being resynced to — i.e., the original source volume. Get the direction wrong and you can overwrite the wrong side. When in doubt, snapmirror show the relationship and follow its arrow.

5. Restoring data from the destination

# Restore the destination snapshot back onto the source volume (in-place restore)
snapmirror restore -source-path vsB:volB -destination-path vs1:vol1
# Or browse the destination via NFS/SMB after break, and copy files back

Restore overwrites the source volume with the destination's data — confirm the snapshot you're restoring is the right one, and snapshot the current source first if there's any doubt.

6. SnapVault / vault relationships

Vault relationships use labels: the source's snapshot policy must create snapshots with matching labels (e.g., daily, weekly), otherwise nothing transfers. Check both policies: snapshot policy show and snapmirror policy show.
Retention is per-label on the destination — "why isn't my weekly kept for 5 years?" is usually a label mismatch.
Verify/release: after breaking a vault relationship for testing, re-establish with snapmirror create + resync, or snapmirror release to clean up source-side state.

7. Prevention checklist

Thin-provision destinations; monitor destination aggregate usage.
Alert on lag: snapmirror show -fields lag-time in your monitoring, threshold on your RPO.
Don't let autodelete remove snapshots the relationship still needs — configure autodelete with snapmirror protection awareness (autodelete won't delete snapshots needed by SnapMirror when configured correctly).
Document your DR runbook: break → fail over → resync → switchback. Test it — the exam and the real world both reward a tested runbook.

← All troubleshooting guides