FREE TOOLS / RTO · RPO
RTO / RPO calculator
Two numbers describe your entire disaster story: RPO — how much data you'd lose, set by how often backups run — and RTO — how long until you're back, set almost entirely by whether you've ever practiced the restore. Most teams have never put numbers on either. Set your current reality below and see them; nothing leaves your browser.
── RECOVERY PROFILE ───────────────────────────── WORST-CASE DATA LOSS (RPO) ~24 hours of writes TYPICAL DATA LOSS ~12 hours of writes ESTIMATED RECOVERY TIME (RTO) ~4.2 hours (unproven restore path) BLAST RADIUS shared — backups share fate with the platform and account they protect ───────────────────────────────────────────────── Estimates — the only real RTO is a measured drill.
- Run one restore drill this week. An untested backup is a hypothesis, and the 4-hour fumbling overhead above is the optimistic case — drills are what turn it into 10 minutes.
- Deploys are the gap schedules can't close: a migration that goes wrong at 4:55 PM needs a checkpoint from 4:54, not last night's snapshot.
- Keep one copy off-platform, in a bucket you own. Account lockout, billing lapse, and platform incidents take the database and its on-platform backups down together.
How to read your numbers
- RPO is a choice you make in advance. Worst-case loss equals your backup interval — an incident at the end of the window takes the whole window with it. Daily backups mean accepting that any day can lose up to a day.
- RTO is dominated by practice, not hardware. The data transfer is minutes per gigabyte; the hours come from discovery — locating the artifact, recalling the procedure, debugging the role error on the first attempt. A drilled restore collapses that overhead to minutes.
- The deploy gap is real. Scheduled backups bound everyday risk, but a bad migration lands between snapshots by definition. A checkpoint sealed seconds before each migration is what closes that window.
- Stated objectives need evidence. If a customer or auditor asks for your RPO/RTO, the credible answer is a number plus proof — a monthly restore-drill report with measured restore times, not an estimate from a calculator (including this one).
FAQ
What's the difference between RTO and RPO?
RPO (recovery point objective) is how much data you can afford to lose, measured backwards from the incident — it's bounded by your backup frequency. RTO (recovery time objective) is how long until you're running again — it's bounded by how practiced your restore is. They're independent: hourly backups with an untested restore give you a good RPO and a terrible RTO.
What are reasonable RTO/RPO targets for a small SaaS?
For a product with paying customers: RPO of one hour (hourly snapshots, plus a checkpoint before every migration) and RTO under an hour (which requires a restore path you've actually exercised). Pre-revenue projects can live with daily/half-day. Enterprise contracts and SOC 2 reviews often ask you to state both numbers and show evidence.
How do I improve my RPO?
Increase backup frequency (hourly instead of daily cuts typical loss 24×), add WAL archiving or PITR if your platform offers it, and seal a tagged checkpoint before every migration — deploys are where the gap between scheduled backups actually bites.
How do I improve my RTO?
Practice. The first restore you ever run shouldn't be during an incident: it's hours of finding the artifact, remembering the procedure, and debugging role or version errors. A restore that's drilled regularly takes minutes and you know its duration instead of guessing. That's why OffsiteDB restore-drills every snapshot and reports measured restore times.
How accurate are this calculator's numbers?
They're honest estimates: worst-case RPO is exactly your backup interval; restore throughput assumes roughly 1 GB/min for a practiced pg_restore, slower for unpracticed paths; the cost figures spread monthly revenue evenly over 730 hours. Treat them as the shape of the risk, not a promise — the only real RTO is one you've measured with a drill.
Do auditors actually ask for RTO and RPO?
Yes. SOC 2, ISO 27001, and most enterprise security questionnaires ask you to state recovery objectives and demonstrate that backups are tested. A stated RPO/RTO backed by monthly restore-drill evidence answers the question in one attachment; 'we have backups' does not.
Want the practiced-restore numbers?
OffsiteDB gives you hourly snapshots (RPO: 1 hour), restore-drills every one on real Postgres, and reports measured restore times monthly — so your RTO is a number you know, not one you estimate. Start free, or work through the restore drill checklist to measure yours by hand.