SnapMirror Lag After Application Change Rate Jump
A 50TB volume on an AFF source in New York is protected by asynchronous SnapMirror to a FAS destination in Dallas over a 1Gbps WAN with 40ms RTT. The relationship transfers hourly. The application change rate was 2% per hour but has jumped to 12% per hour after a new release. SnapMirror lag is now six hours, snapshots are accumulating on the source, and the destination volume is 70% full. The source volume is 60% full. The team is considering increasing the SnapMirror schedule frequency to every 15 minutes and deleting older SnapMirror snapshots on the destination to free space.
1. Quantify whether the WAN can support the new change rate and evaluate the proposed remedies.
Read the worked answer
At 50TB with a 12% hourly change rate, the source generates about 6TB of changed data per hour, or roughly 1.67GB/s, which is about 13.3Gbps. A 1Gbps link carries at most about 125MB/s, or roughly 450GB per hour at line rate, and less in practice. The WAN is therefore short by more than an order of magnitude. Lag will grow until the relationship cannot catch up.
Changing the schedule to every 15 minutes does not reduce the data volume; it just creates more transfer attempts and more snapshots. Deleting snapshots on the destination without understanding the relationship can break the common Snapshot baseline and force a much larger transfer. The correct conclusion is that the WAN is the bottleneck, not the schedule.
2. What options would you evaluate, and what risks must be managed while the lag is high?
Read the worked answer
Evaluate bandwidth upgrade or WAN optimization first, because compression alone will not close a 13x gap. SnapMirror network compression and source deduplication/compression can reduce data, but they are not a substitute for adequate bandwidth at this change rate. Consider whether the application can reduce change rate, whether a different replication target or local protection is needed, and whether a temporary seeding or transfer window is required.
While lag is high, monitor source snapshot growth and destination capacity; do not let the destination fill. Do not delete SnapMirror snapshots blindly. Confirm which snapshots are required for the next incremental transfer and use supported snapshot management. Check snapmirror show for lag time, health, and transfer state. If the relationship is too far behind, plan a controlled resync or baseline rather than assuming normal incrementals will recover.