RPO and RTO: definitions and calculator
The RPO is the maximum acceptable data loss: how much time worth of entries you can lose. The RTO is the maximum acceptable downtime: how long the service can stay unavailable.
The calculator below estimates the ones your backups actually allow, and shows which step weighs most.
The calculation runs in your browser: nothing you type is sent anywhere.
Calculate the RPO and RTO of your backup
Result
Resulting RPO
1 d 0 h 30 min
Interval + duration of one backup · target: 1 h
Resulting RTO
2 h 42 min
target: 4 h
RTO breakdown
| Detection | 15 min | 9% |
| Response | 1 h | 37% |
| Transferring data back | 57 min | 35% |
| Return to service | < 1 s | 0% |
| Checks | 30 min | 18% |
RPO and RTO on a timeline
The two objectives sit on either side of the incident. The RPO is measured backwards, to the last usable restore point. The RTO is measured forwards, to the return to service.
last backup incident back online
|<------- RPO ------->|<----------- RTO ----------->|
data lost service unavailableBoth are set business line by business line, before choosing a technique. Email often tolerates a few hours of RPO; an order database, a few minutes. That choice then decides backup frequency, log shipping and the recovery architecture.
How the calculation works
The RPO takes the worst case: the incident happens just before the next backup finishes.
RPO = interval between backups + duration of one backup
(or the log shipping interval, if shorter)
RTO = detection + response
+ transfer back (data × 8 / (bandwidth × efficiency))
+ return to service (data / reload speed)
+ checksThe transfer counts GiB in binary (2³⁰ bytes) and bandwidth in decimal Mbit/s, as network tools do. Efficiency corrects the gap between link speed and useful throughput: protocol, encryption, server load. Return to service covers what follows the transfer, such as reloading an SQL dump. For a VM restored directly, it is negligible.
What our measurements show
For a MariaDB database, our method for backing up MariaDB to Proxmox Backup Server sends a dump every night and binlogs every 5 minutes. Point-in-time restore is validated there: 180,000 rows out of 180,000 recovered after a faulty DROP TABLE. That is the calculator's "daily + binlogs" preset: the RPO goes from over 24 hours to 5 minutes.
On RTO, the same page compares two restore modes on our small test databases: 43 s to transfer back and bring online a 4.05 GiB physical copy, against about 195 s to transfer back and reload a 1.7 GiB dump. These are the Only the physical copy is used as a reference point in the calculator. Reloading a dump depends on indexes and does not scale linearly: a speed taken from 1.7 GiB would give a wrong RTO on 100 GiB. Measure it on your database. Both durations include the transfer and come from small databases: do not take them as a promise for yours. The dump tool matters too, as our comparison of mariadb-dump and mydumper shows.
For a file server, the first backup of a 1 TB Windows server took 20 h 30 for 876 GB. That is an upload, not a restore, but it gives the order of magnitude of real throughput on an ordinary internet line. To estimate your own upload times, the backup window calculator does the reverse calculation.
Lowering your RPO or RTO
The RPO goes down by backing up more often or by shipping transaction logs between backups. For virtual machines, a 3-2-1 backup strategy across several datacenters keeps a recent copy away from the production site.
The RTO goes down first on the human steps. Detection depends on monitoring, response on someone being there at 3 a.m.: that is the job of 24/7 IT on-call support. The transfer shrinks by keeping a copy close by; the rest needs a recovery architecture. Our article on the multi-site Proxmox disaster recovery plan describes that setup, and the page on Proxmox disaster recovery with PBS covers recovery from an offsite backup. To frame the organisational side, see DRP and BCP with managed services.
The RTO then translates into availability: a few hours of downtime a year weigh on an SLA, which our uptime calculator quantifies. And if the transfer crosses a distant link, the TCP throughput calculator shows what latency takes away from useful throughput.
Frequently asked questions
What is the difference between RPO and RTO?
The RPO (Recovery Point Objective) is the maximum acceptable data loss, expressed as time: with a 24-hour RPO, you accept losing up to one day of entries. The RTO (Recovery Time Objective) is the maximum acceptable downtime, between the incident and the service coming back. The RPO looks back, to the last usable backup; the RTO looks forward, to the return to service.
How do I calculate the RPO of a backup?
In the worst case, the incident happens just before the next backup finishes: you lose the interval between two backups plus the duration of one backup. A daily backup that takes 30 minutes gives an RPO of 24 h 30 min. If transaction logs (MariaDB binlogs, PostgreSQL WAL) are shipped every 5 minutes, the RPO drops to 5 minutes.
How long does it take to restore 1 TB?
Transferring 1,000 GiB back over a 1 Gbit/s link used at 50% takes about 4 h 46 min on its own. Add incident detection, the time before someone responds, the return to service (reloading a dump, for example) and the checks before going live. The transfer is often only part of the RTO.
Dump or physical copy: what effect on a database's RTO?
A dump is restored by replaying every SQL statement and rebuilding indexes; a physical copy goes back in place at disk speed. On our small test databases, transfer included, a 4.05 GiB physical copy was back in service in 43 s, against about 195 s to reload a 1.7 GiB dump. These speeds are not guaranteed on a large database: measure yours.
Is a calculated RTO enough for a disaster recovery plan?
No. The calculation gives an order of magnitude and shows which step weighs most. Only a timed restore test, on a real copy of your data, gives your true RTO. An RTO that was never tested is an assumption, not a commitment.
Contact
Address
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE