DevOps · interactive

Backups, RPO and RTO

At 14:30 a bad migration drops the orders table. Two numbers decide how bad the day gets: RPO, how much data you lose (back to your last restore point), and RTO, how long you're down while restoring.

drop table at 14:30

00:0012:0024:00

Ticks: restore points. Red: data lost.

Restore to: 02:00
RPO (data lost): 12.5 h
RTO (downtime): ~95 min

~15,000 orders lost

The last backup is from 02:00, so twelve and a half hours of orders are gone, and restoring a full dump is slow.

Backup strategy

Step 1 of 4 · read left to right

1
RPO: how much can you lose?
The gap between the last restorable point and the disaster. Set it with the business: an hour of orders? A minute?
Recovery Point Objective.
2
RTO: how long can you be down?
Time to provision, restore, replay and verify. Big databases take hours to restore from scratch.
Recovery Time Objective.
3
Replication copies mistakes too
A DROP TABLE reaches every replica in milliseconds. Only point-in-time backups take you back before the mistake.
Keep copies in another account and region.
4
An untested backup is a hope
Restore regularly into a scratch environment, time it, and check the data. That's your real RTO.
Automate the restore drill.

In production

Tools and technologies

Managed databases offer snapshots and point-in-time restore.

Not tied to one language — use these names when you search docs or design a system.