# RPO and RTO

> How much data you can afford to lose and how long you can afford to be down — the two numbers behind every backup plan.

Concept · Running systems · https://levelcode.org/concepts/rpo-rto

"We have backups" isn't a recovery plan. A plan starts with two numbers, agreed with the business **per system**:

- **RPO (recovery point objective):** the maximum acceptable **data loss**, measured in time. RPO = 1 hour means losing the last hour of writes is acceptable; losing more isn't.
- **RTO (recovery time objective):** the maximum acceptable **downtime**, from the incident until the service works again.

```text
        last good backup          disaster                  service restored
───────────────●──────────────────────✖───────────────────────────●──────────▶ time
               └────── data lost (≤ RPO) ──┘└──────── downtime (≤ RTO) ────────┘
```

## What the numbers dictate

| Target | Typical approach | Cost |
|---|---|---|
| RPO 24 h, RTO 1–2 days | Nightly backups, manual restore | Low |
| RPO ~5–15 min, RTO hours | Continuous WAL/binlog archiving with point-in-time recovery; scripted restore | Moderate |
| RPO ≈ 0, RTO minutes | Synchronous [replication](https://levelcode.org/concepts/leader-follower-replication) to a standby, automated failover | High |
| RPO ≈ 0, RTO ≈ 0 across regions | Multi-region active-active | Very high, plus [consistency](https://levelcode.org/concepts/cap-theorem) trade-offs |

Getting each number closer to zero costs a lot more, which is why the business has to own the target. Most systems don't need the bottom rows.

## Replication isn't a backup

A replica copies **every change**, including `DROP TABLE`, a bad migration, or ransomware encrypting your data, within milliseconds. Replication protects against *hardware* failure. Backups protect against *mistakes and attackers*. You need both:

- **3-2-1:** three copies, on two kinds of storage, one off-site. Add **one immutable copy** (object lock, write-once storage) that even a stolen admin credential can't delete.
- **Keep enough history** (point-in-time recovery over days or weeks) to reach a moment before a problem you only noticed later.

## A backup you haven't restored is a hope

- **Run restore drills on a schedule.** Restore into a clean environment, time it, and compare the time with your RTO.
- **Alert when a backup is missing, not only when one fails.** Silence is the common failure mode.
- **Account for dependencies.** Restoring the database within RTO doesn't help if the secrets, DNS or deploy pipeline it needs are gone too.

RPO and RTO apply to recovering from disasters. Day-to-day uptime is covered by [availability targets](https://levelcode.org/concepts/availability-and-nines). The [backup lesson](https://levelcode.org/roadmaps/devsecops/backup-and-recovery) builds a full plan.