Why does a standby replica of a managed store give a near-zero recovery point yet fail to protect against a mistaken bulk delete?

## Two mechanisms, two different enemies The pair of recovery numbers is bought with two mechanisms that are constantly confused, because both produce "another copy of the data". A **standby replica** is a second running copy of the store that continuously applies the primary's committed writes. Under **synchronous replication** the primary does not acknowledge a write until the standby has it, so the replica is never behind and the recovery point is effectively zero; under **asynchronous replication** the standby trails by a **replication lag** and the recovery point is roughly that lag. Recovery is by **promotion**: the standby becomes the primary. The enemy it defeats is the loss of the failure domain the primary sits in. A **point-in-time restore** rebuilds the data as it stood at a chosen moment. It is normally assembled from a base capture plus the change record that follows it, which is why the moment can be chosen with fine granularity rather than only at capture boundaries. The enemy it defeats is **logical corruption**: a mistaken bulk delete, a migration that rewrote the wrong rows, a defect that quietly corrupted values for hours. ## Why replication cannot save you from a mistake Replication is deliberately faithful. It has no notion of intent, so a delete issued by an authorised session is simply a committed write, and a correctly functioning replica applies it as promptly as it applies anything else. That faithfulness is the feature: a replica that diverged from its primary would be useless for failover. The consequence is the rule worth memorising: > Replication protects against losing a copy. Retention protects against changing a copy wrongly. The corollary is that a mirrored store is **not** a backup, however many copies exist, and "we replicate to three places" is not an answer to "what happens when someone runs the wrong statement". ## Comparing the two along the numbers they buy | | Standby replica | Point-in-time restore | |---|---|---| | Recovery point | zero under synchronous replication, roughly the lag otherwise | the granularity of the change record, inside the retention window | | Recovery time | short — promote and repoint clients | long — provision, copy, replay, cut over, verify | | Protects against | loss of the failure domain holding the primary | a bad write, a bad migration, a corrupting defect | | Does not protect against | anything committed by an authorised caller | anything older than the retention window | | Cost shape | a second store running continuously | storage of captures and change records, plus the restore itself | ## What the retention window bounds A restore can only reach back as far as the **retention window** the service keeps. Two consequences follow, and both show up in interviews: - A corruption discovered after the window has rolled past is unrecoverable from that store, whatever the durability of the underlying storage. Slow-burning logical corruption is therefore far more dangerous than a loud failure, because detection time competes with the window. - Extending the window is a real purchase, and providers differ in how far the window can be pushed and in what it costs, so the number is a design decision rather than a default to accept quietly. ## What a restore actually hands you A restore does not rewind the existing store in place. It normally produces a **fresh store** holding the chosen state, sitting at a new address, while the damaged original is still running. That is deliberate — it preserves the evidence and lets you compare — but it means the restore is not the end of the recovery. Somebody has to decide the store is correct, cut traffic over to it, and deal with everything that was written to the damaged original in the meantime. In the payments case, that reconciliation is often the slowest part: the ledger has been taking writes since the bad delete, and rewinding to a moment before it discards those too. This is also why restore duration grows with the amount of data and with the distance between the base capture and the chosen moment: more to copy, and more change record to replay. ## Using both, on purpose A regulated payments ledger typically carries both, for different lines in the recovery table: 1. A closely following standby, so the failure of the primary's failure domain costs seconds of work and a promotion. 2. Restore points with a retention window long enough to cover realistic detection time for a bad write. 3. A written decision about which mechanism answers which incident, because reaching for the wrong one under pressure is how a recoverable mistake becomes permanent — promoting a standby after a bad delete simply installs the corrupted state as the new primary. The reporting copy derived from that ledger usually carries neither at full strength, because it can be rebuilt from the ledger.