How should you test a SnapMirror disaster-recovery relationship?

• A. Only monitor transfer lag.
• B. Run a health check script.
• C. Perform a full database restore.
• D. Regularly perform failover/failback tests and verify data integrity and accessibility at the destination.

Answer: (D)

Testing a SnapMirror disaster-recovery relationship is about proving the DR site can take over and provide valid data access when needed. The best approach is to regularly perform failover and failback tests and verify data integrity and accessibility at the destination. This end-to-end validation confirms that the replication setup will actually support business continuity: the destination can become active, data is consistent, and applications can connect and operate as expected. It also helps verify recovery time and data recoverability goals, and ensures the overall operational workflow—from triggering a failover, to failing back and resynchronizing—works smoothly.

Relying only on monitoring transfer lag doesn’t prove recoverability, since replication speed doesn’t guarantee that the DR path can be used in a real outage or that data remains accessible and correct at the DR site. A health check script might confirm certain health metrics but won’t validate the complete DR process or end-to-end accessibility. Performing a full database restore tests a subset of data and can be disruptive; it doesn’t validate the ongoing DR workflow or broader data and application readiness across the environment. Regular, hands-on test failovers and verifications provide the most reliable assurance that the DR relationship will perform when it’s needed.