---
title: Disaster Recovery: RTO vs RPO explained
description: When the worst happens, two numbers decide how bad it really is: how much data you lose, and how long you're down. Here's what RTO and RPO mean, and how to set targets you can actually meet.
canonical: https://watchfor.io/blog/disaster-recovery-rto-rpo
---

# Disaster Recovery: RTO vs RPO explained

2026-03-21 · WatchFor Team · Reliability · reliability, disaster-recovery, sre

When the worst happens, two numbers decide how bad it really is: how much data you lose, and how long you're down. Here's what RTO and RPO mean, and how to set targets you can actually meet.

A database is corrupted. A region goes dark. A bad migration wipes a table. It *will* happen eventually — and when it does, two questions decide how painful it is: **"How much data did we lose?"** and **"How long until we're back?"**

Those two questions have names — **RPO** and **RTO** — and they're the heart of disaster recovery planning. Get clear on them *before* the disaster, and recovery becomes a procedure instead of a panic.

## The two numbers that matter

When disaster strikes, picture a timeline with the incident in the middle. The two metrics sit on either side of it:

```
last backup ────[ RPO ]────► 💥 incident ────[ RTO ]────► recovered
```

- **RPO (Recovery Point Objective)** looks *backward*: how much **data** can you afford to lose? It's the gap between your last good backup and the moment of failure.
- **RTO (Recovery Time Objective)** looks *forward*: how much **time** can you afford to be down? It's how long recovery is allowed to take.

| Metric | Question | Measured in |
| --- | --- | --- |
| **RPO** | How much *data* can we lose? | Time of data (e.g. "up to 5 minutes") |
| **RTO** | How long can we be *down*? | Time to restore (e.g. "under 1 hour") |

## RPO in plain terms

If your **RPO is one hour**, you're saying: "in a disaster, losing up to the last hour of data is acceptable." That directly dictates how often you back up. Want an RPO of five minutes? You need backups (or replication) at least that often.

- **Daily backups → RPO of up to 24 hours** (you could lose a day's data).
- **Continuous replication → RPO near zero** (almost no data loss).

The smaller the RPO, the more frequent — and usually more expensive — your data protection has to be.

## RTO in plain terms

If your **RTO is one hour**, recovery — detecting, deciding, restoring, verifying — must fit inside an hour. That shapes your *architecture*, not just your backups:

- **Restore from backup manually → RTO of hours** (download, restore, verify).
- **Automated failover to a standby → RTO of minutes** (traffic just shifts).

The smaller the RTO, the more automation and redundancy you need standing by.

## Setting targets that fit

The trick is matching targets to the **business value** of each system — not making everything "as fast as possible," which is ruinously expensive.

1. **Rank your systems.** The payments database and the marketing blog have very different stakes.
2. **Ask the business.** "If we lost an hour of *this* data, what's the impact?" "If *this* was down for four hours?"
3. **Set RPO/RTO per system** based on those answers — tight for critical, relaxed for the rest.
4. **Cost it.** Tighter targets cost more (more frequent backups, hot standbys). Pay for it where it matters.

> **The hardest-won lesson:** an untested disaster-recovery plan is just a hopeful document. **Practise it.** Run a real restore. Time it. The first time you test, you'll discover the backup that wasn't actually running, or the restore that takes three times longer than assumed — and you'll find out on a calm Tuesday instead of during the real thing.

## How this connects to the rest

DR targets are cousins of your [SLAs and SLOs](/blog/sla-slo-sli) — they're reliability promises, just for catastrophic events rather than everyday ones. And they defend against the big items on the [website downtime](/blog/website-downtime-causes) list: data loss, regional failures, corruption.

## The bottom line

| | In one line |
| --- | --- |
| **RPO** | How much data you can lose — sets backup frequency. |
| **RTO** | How long you can be down — sets your architecture. |
| **Set by** | The business value of each system, not "as fast as possible". |
| **Then** | Test the plan — an untested DR plan is a guess. |

Disaster recovery isn't about preventing every catastrophe — it's about deciding, in advance and on purpose, how much you can lose and how fast you'll be back. Define RPO and RTO per system, build to meet them, and *rehearse* — so the worst day is survivable, not existential.

Reliability targets for the everyday kind start with [SLA vs SLO vs SLI](/blog/sla-slo-sli).

---

Canonical page: https://watchfor.io/blog/disaster-recovery-rto-rpo · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt