RTO and RPO for small teams: the two numbers that price your backups

Every disaster-recovery document has two acronyms in it, and most small teams copied them from an enterprise template: RTO 4 hours, RPO 15 minutes. Then the disk dies on a Thursday evening, and the real numbers turn out to be RPO 22 hours (the nightly dump ran at 02:00) and RTO 19 hours (nobody had ever restored it before). The declared numbers were not a plan; they were a mood. RTO and RPO are useful exactly when they are treated as prices: RPO is how much work you can afford to lose, RTO is how long your customers can afford to wait, and every improvement in either costs real money every month.

This note defines the two numbers in customer terms, sets them per service tier so they are affordable, shows the arithmetic that prices them, lists the five traps that make them lie, and gives a one-afternoon rollout anchored on a restore drill you can run this week.

1. What the two numbers actually mean

• RPO — recovery point objective — is how much work disappears. It is a clock-face gap: the distance between the last restorable copy and the moment of failure. RPO of 24 hours with a nightly dump means the customer loses a day of entered data, and support spends the next week re-keying it with them. The honest question to ask per service: if N hours of data vanish, what does the customer actually lose, and who re-enters it?
• RTO — recovery time objective — is how long until customers can work again. Not until the server boots: until the service catalog's written promise (“accepts payments”) is being kept again. A VM that boots in 10 minutes and serves errors for six more hours has an RTO of six hours, no matter what the doc says.
• The third number: measured RTO. The only RTO that exists is the one you have timed on a real restore. Declared minus measured is not a rounding error — it is the risk, and it never shrinks on its own.

2. Set them per tier, not per company

One pair of numbers for the whole company is a category error: the checkout database and the internal wiki do not have the same value per hour. Set RTO/RPO where the tiers already live — the service catalog — and let the tier do the arguing:

• Tier 1 (customers feel it in minutes): RPO in minutes — streaming replication or managed point-in-time recovery. RTO in tens of minutes — a failover that has been rehearsed, with the promotion steps on one page.
• Tier 2 (workaround exists): RPO up to 24 hours — a nightly dump with tested restore. RTO up to a business day.
• Tier 3 (internal): RPO a week, RTO best effort, said out loud. Pretending otherwise spends tier-1 money on tier-3 comfort.

The test for each number is affordability: write down what the next 10× improvement costs — managed PITR vs nightly dumps vs a warm standby — and pick the cheapest number the business can actually absorb. A number you cannot afford to implement is not an objective; it is a wish with an acronym.

3. The arithmetic that prices the promise

• RPO costs storage and replication, monthly: a nightly dump is nearly free; hourly binlog shipping costs a little; continuous PITR costs the most. The bill is steady; the loss it prevents is lumpy and rare. That asymmetry is why the number gets decided calmly, on a Tuesday, instead of during the outage.
• RTO costs capacity and rehearsal: a warm standby burns money monthly whether or not it ever fails over, and a cold restore costs the hours it takes to run — which you only know if you have run it. Rehearsal is the cheapest RTO you can buy.
• Every 10× improvement is usually a different mechanism, not more of the same: 24h→1h is dump frequency; 1h→5min is replication; 1h→10min is a warm standby and runbooks. Price the jumps, then buy the one the tier needs.

4. The five traps

Declaring enterprise numbers with small-team plumbing. RPO 15 minutes written above a nightly cron job is not ambition, it is fiction with a footer. Measure the current gap first (when did the last restorable copy happen?), then declare, then buy down if the tier needs it.

RTO measured to “server up.” The database host is back; the app now replays two days of queue, rebuilds search indexes, and support answers “where did my Tuesday go?” The customer clock runs until the promise is kept — the severity language you already use should end at the same line.

Backups that have never been restored. A backup is a hope until a restore has been run end to end — same law as the untested rollback script in the change review. The restore drill checklist exists because the first drill almost always finds that the dump is fine and everything around it (credentials, network path, disk space, ordering) is not.

One number for the whole company. The DR PDF says 4 hours; the ingest pipeline's customers lose a day and the checkout queue loses nothing, because they have different tiers. Declare per service, per tier — or the number is an average of things that never happen.

Numbers that grew stale silently. The RTO was rehearsed when the database was 20 GB; two years later the restore takes nine hours and the dump window overlaps business hours. RTO/RPO decay as data grows — which is why the drill is a calendar event, not a memory.

5. Worked example

An eight-person B2B expense tool declares “RTO 4h, RPO 1h” in its security questionnaire. The plumbing underneath: a nightly database dump at 02:00, never restored, on the same availability zone as the primary. A disk failure on the database host lands at 18:40 on a Thursday. Recovery takes 22 hours — a new host, a permissions puzzle, a 14-hour dump restore — and the company loses 17 hours of customer receipts (the real RPO was 24h minus four).

The redo takes one afternoon and $85/month. They restore the existing dump into a scratch host and measure: 3h40m, most of it dump-transfer. Tier-1 database moves to managed point-in-time recovery (RPO 5 minutes, measured by the provider's SLA and spot-checked monthly), and a read replica gets a rehearsed promotion runbook — promoted in a drill in 41 minutes end to end. New declared numbers, per tier: checkout RPO 5 min / RTO 1 hour; reporting RPO 24h / RTO 8h; internal tools RPO 7d / best effort. The next real failure — six weeks later, an hour-long provider outage — costs 40 minutes of replica lag and one status-page update. The counter-example is the competitor whose DR PDF promised RPO 15 minutes while the “replication” was an rsync cron job to a server in the same rack; their real outage lost three days, and the PDF survived as a sales artifact.

6. Metrics (for the metric itself)

• Every tier 1–2 service has a declared RPO and RTO, one line each, traceable to its catalog tier.
• A restore is measured at least twice a year — and declared ≥ measured always; when measured exceeds declared, either fix or re-declare within the week.
• The monthly price of each number is written next to it, so the next downgrade-or-upgrade debate starts from money, not vibes.
• Drills are calendar events with owners, not crisis memories.
• The numbers are re-checked when data volume doubles — that is when quiet decay happens.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the disaster recovery plan template for small teams is the document these two numbers anchor, the backup restore drill checklist is how measured RTO gets its number, and the restore test template is the recurring version.