After a database is recovered to an earlier point and then opened for writes, its history forks into a new branch. What does that fork mean for the archived transaction logs, for existing replicas, and for future recoveries?

## Why a branch identifier exists at all A transaction log is an append-only stream addressed by position. During recovery you deliberately stop before the end of that stream and discard what follows. The moment the recovered instance accepts a write, it must produce a log record - and the natural next position is one the archive already contains from the abandoned history. Without a disambiguator you would have two different records claiming the same address, and any later recovery would be unable to tell which history it was replaying. Engines solve this by tagging the log stream with a **timeline** or branch identifier that increments on every promotion, plus a small **history record** stating which branch it forked from and at what position. Archived segments are named or filed per branch, so both histories coexist. ## What this buys you - You can still recover to any point on the **old** branch, because its segments remain intact and identifiable. That matters when you discover your recovery target was wrong. - You can recover to a point on the **new** branch, and the engine knows to follow the old branch up to the fork, then switch. This is why the history metadata must be retained alongside the segments; deleting it can make an otherwise complete archive unusable. - Repeated recoveries create repeated branches; the history records form a small tree, and any recovery target must be qualified by which branch you mean. ## What it costs you **Replicas become invalid.** A standby that was streaming the old history has already applied transactions that the promoted server never had. It is not merely behind - it is *divergent*, holding records that contradict the new history at the same positions. Streaming cannot continue. The options are: - rebuild the standby from a fresh base backup of the promoted server, which is simple, safe and expensive in time and bandwidth; - use a resynchronisation tool that rewinds the standby to the fork point by undoing its divergent records and then lets it follow the new branch, which is much faster but only works when the standby retains enough information to do so. **Split brain becomes possible.** If the original primary is still running and accepting writes while the recovered copy is promoted, you have two servers with the same identity producing two branches of real, committed business data. There is no automatic reconciliation for that. Fencing the old primary - stopping it, revoking write access, removing it from the load balancer and from any automatic failover manager - is part of the promotion procedure, not an afterthought. **The archive becomes shared and confusing.** If several recovered instances write into the same archive location, branch identifiers keep their segments distinct, but retention and monitoring become harder to reason about, and a mistake in archive configuration can result in one instance overwriting another's segments. Many teams route each recovered instance to its own archive prefix precisely to avoid that. **Recovery time grows.** Immediately after a promotion, your only base backup predates the fork. Restoring to a point on the new branch means restoring that old backup, replaying to the fork, and then replaying forward along the new branch - a long, multi-stage path with more moving parts than a normal restore. Taking a fresh base backup on the new branch as soon as the instance is live collapses that path back to normal and is the standard first post-recovery action. ## Post-recovery checklist 1. Fence the old primary; make it impossible for it to accept writes or be promoted by an automatic failover manager. 2. Verify the new branch identifier and confirm the archive contains the branch-history record. 3. Take a fresh base backup on the new branch and verify archiving is working from the new instance. 4. Rebuild or resynchronise every replica; do not let a divergent standby be used for reads, because it serves transactions that no longer officially exist. 5. Adjust retention so the old branch's segments survive as long as you might still want to recover to a point before the fork. 6. Reset monitoring and connection routing to the new instance, and reconcile downstream consumers - queues, caches, search indexes, data warehouses - that consumed the abandoned transactions. The conceptual point worth carrying away: recovery is not a rollback of a single database's contents. It creates a new lineage, and everything that was coupled to the old lineage - standbys, backups, downstream data copies - is coupled to a history that no longer exists.