Test-failover and failback
Test-failover
Starting with 14.0.0.0, a test-failover can be performed to validate that the failover actually works when disaster strikes. The failover operation can be undone by doing a failback operation.
The failback operation takes the replication target back to the pre-failover state so that replication incremental can be received.
During failover, there is an option to save the state so that a failback can be performed. This is the enableFailback option and it is turned on by default.
Once failover is complete, environments and datasets may be enabled and activated as mentioned in Controlled failover.
A test-failover does not place restrictions on the kinds of operations that may be performed on the failed over data. Environments and datasets may be enabled and used. New snapshots may be created. New VDBs may be provisioned from the failed-over datasets.
Failback
On failback, all newly provisioned child datasets will be destroyed. All new snapshots and refreshed time-flows will be deleted. The target-replication engine will thus be brought back to the state prior to failover by moving the objects into a read-only replica namespace so that the replication-source engine can continue replicating to the replica namespace.
No changes are made to the replication-source engine during failback. No changes from the replication target are propagated back to the replication source. Thus failback can be thought of as an “undo failover” operation.
Full restoration of the Received Replica namespace requires a successful replication-receive from the replication-source engine after performing the failback operation. It is a best practice to do this right after a failback.
The replication profile on the replication-source engine needs to be preserved for receiving updates to the Received Replica namespace.
Commit failover
If a failback is unnecessary, the test failover can be committed, making the failover permanent. This is similar to performing a failover with the enableFailback option off.