Someone runs a DELETE without a WHERE clause against a production table at 14:31. Every replica applies it faithfully within milliseconds. High availability worked perfectly and made things worse.
Replication protects against a machine failing. It does nothing about a mistake, because a mistake is a valid transaction that replicates like any other.
What changed in 2026
- Managed platforms made it standard. Continuous archiving with a retention window became a default feature rather than a configuration project.
- Recovery time got scrutinised. Teams began measuring how long a restore actually takes rather than assuming.
- Restore drills became expected practice. Testing recovery moved from good hygiene to a routine requirement — see restore drills.
- Logical backups regained a role. Alongside physical recovery, table-level logical dumps became a common complement for selective restores.
How it works
Two components.
A base backup — a full copy of the database at some moment.
Archived write-ahead log segments — every change since that moment, retained continuously.
Recovery restores the base backup and then replays log segments up to a chosen target time. Stop replaying at 14:30 and you have the database as it was one minute before the deletion.
The window you can recover to is bounded by how far back your base backups and archives go. That retention period is your real recovery capability, and it is worth knowing rather than assuming.
Recovery time depends on backup frequency
The consequence people discover during an incident.
Recovery time is dominated by replaying logs from the base backup to the target time. A base backup from a week ago means replaying a week of changes, which on a busy database can take hours.
| Base backup age |
Log replay |
Recovery time |
| Hours |
Small |
Fast |
| A day |
Moderate |
Moderate |
| A week |
Large |
Hours |
| A month |
Very large |
Impractical |
So base backup frequency is really a recovery-time decision. More frequent base backups cost storage and reduce the time to recover. If your recovery objective is measured in minutes, a weekly base backup cannot meet it regardless of how complete your archives are.
Two numbers are worth stating explicitly and measuring rather than assuming: how much data you can lose (bounded by archive frequency) and how long recovery takes (bounded by backup frequency and replay speed).
Restoring in practice
Restore to a new instance. Never over the original. You may need to try several target times to find the right moment, and the original may contain data written after the incident that you want to preserve.
Finding the target time is frequently the hard part. You know roughly when the mistake happened, and narrowing it precisely usually means examining logs. Restoring to a slightly earlier time and comparing is a practical approach.
Extract rather than replace, where possible. For an accidental deletion of one table's rows, restoring a copy and copying the missing rows back is far less disruptive than replacing the whole database and losing everything written since.
That approach preserves subsequent legitimate work, which a wholesale restore discards.
Test it. A backup that has never been restored is an assumption. Restoring on purpose, on a schedule, is the only way to know the archives are complete, the process works, and how long it takes — see backup verification.
Common mistakes
- Treating replication as backup. It replicates mistakes.
- Infrequent base backups. Recovery time becomes impractical.
- Never testing a restore. Discovering it fails during an incident.
- Restoring over the original. Loses everything since, and forecloses retries.
- Not knowing the retention window. Your actual recovery capability.
- Archives on the same storage as the database. A storage failure takes both.
- No documented procedure. Improvising recovery under pressure.
FAQ
How often should I take a base backup?
Frequently enough that log replay fits your recovery time objective. Daily is common; hourly for systems where recovery time is critical.
Does this protect against corruption?
Sometimes — if the corruption occurred at a known time, restoring to just before it works. Gradual corruption that went unnoticed may exist in your base backups too, which is an argument for longer retention.
Can I recover a single table?
Not directly with physical recovery — you restore the whole database and extract what you need. Logical dumps complement this by enabling table-level restore.
How long can I go back?
As far as your oldest retained base backup plus continuous archives. Know this number; it is your actual recovery capability.
Where to go next
For confirming backups actually work, read backup verification and restore drills. For why replication is not sufficient, replication lag and write-ahead logging.