Network & Infrastructure / High Availability & Recovery Design
Failback data direction after disaster-recovery activation
A recovered primary site is restarted after the secondary has accepted new writes. Resuming the old replication direction can overwrite the current authoritative state.
Environment and inputs: Routed and clustered services; define failure ownership, fencing and application recovery requirements before testing. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Record current write ownership, replication positions, application consistency and the intended failback procedure. Treat the recovered site's older data as evidence, not automatically as the preferred source.
Explain the result
Site preference and data authority are different decisions. Once recovery operations accept writes elsewhere, the original primary may no longer contain the newest valid history.
Plan the fix
Follow the application's supported resynchronization and ownership-transfer workflow, including backup or preservation of both states where required. Prevent writes on the returning side until authority is established.
Check the result and rollback
Verify transaction markers and one write owner before moving clients back. Abort failback if histories diverge beyond the supported reconciliation method or the proposed direction would discard committed work.