Failback
Returning to the primary region after a failover, including reconciling the data written while it was unavailable — the half of DR that is usually unplanned.
Failover plans are written and occasionally rehearsed. Failback is often not considered until an organisation is operating from its secondary region and discovering that returning is harder than leaving.
The difficulty is data. While running in the secondary, writes accumulated there. The primary's data is stale, and if the failover was caused by a partition rather than a total loss, the primary may hold writes the secondary never saw — which is divergence with no automatic merge.
A workable failback sequence: stop or drain writes in the secondary; reverse replication so the primary catches up; verify convergence with a reconciliation check rather than an assumption; shift traffic gradually, not in one cut; and keep the secondary warm until confidence is established.
Two decisions worth making in advance. Whether to fail back at all — if the regions are symmetrical, staying put is often correct, and organisations that treat regions as interchangeable simply alternate. And whether failback happens under time pressure: it should not, so the plan should permit running in the secondary for days or weeks.
The test of a DR plan is not whether failover works. It is whether the organisation can return to a normal, fully-redundant posture afterwards.