Using Failover for a 24-Hour DR Test
Two PowerStore 5000T systems protect a 40-volume Oracle estate. Production is at site A, DR at site B, and all 40 volumes are in one volume group with asynchronous replication and a 15-minute RPO. The replication session is healthy and lag is under two minutes. The business wants a 24-hour DR test at site B: mount the replicated volumes to test hosts, run read/write validation, and then return to normal. The DR coordinator proposes using the 'failover' operation on the replication session at the start of the test because it is the fastest way to make the destination writable. Production will remain online and active during the test. No change window has been requested, and the test hosts are already zoned to site B. The team has not documented a failback procedure.
1. Assess the failover proposal: what protection and operational risks does it create?
Read the worked answer
Failover makes the destination volumes writable and changes the replication relationship. While production stays online, changes made at site A during the test are not protected at site B, so the 15-minute RPO is not maintained. The test also writes to the DR copy, so returning to normal requires a failback or resync, which can involve a full copy, and the team has no documented failback. A 24-hour test with no change window turns a validation exercise into an unplanned DR event. That is too much risk for a test.
2. Propose a safer test method and state when real failover is acceptable.
Read the worked answer
Use a copy that does not alter the live replication session. Create a snapshot or clone of the destination volumes, or a production snapshot presented to isolated test hosts, and map that copy to the test hosts. Keep the replication session in its normal state so production remains protected and lag stays within RPO. If the array supports a test-failover workflow, use it and keep production replication intact. Real failover is appropriate only for an actual disaster or a planned DR exercise with a change window, application quiesce, and an approved failback runbook.
3. What would you verify before and after the test?
Read the worked answer
Before the test, record replication lag, RPO, destination snapshot space, and the exact volume group membership. Confirm test hosts are zoned only to the copy and cannot write to production. After the test, verify the replication session is still healthy, lag is back under the RPO, and no production volume was accidentally mapped to test hosts. Check that the test copy is deleted or retained per policy, and review the test results against the runbook. If a real failover was performed, verify reverse replication and application consistency before declaring success.