RTO and RPO: how much you'd lose, and for how long
Two numbers decide what a server failure costs you: how much data is gone, and how long you are down. Here is what they mean, and a three-question calculator for what your backups really give you.
Recovery point objective (RPO) is the most data you can afford to lose, measured back in time from the failure. It is set by how often you take a recovery point: a nightly backup means up to 24 hours of orders, sign-ups or edits gone.
Recovery time objective (RTO) is the longest you can afford to be down, measured forward from the failure. It is set by how long a restore takes in practice, from the first alert to the application working, not just how long the files take to copy.
What your backups really give you
Three questions about your main database or server.
A day of data is at risk, and an untested restore is the slow part. A written, rehearsed restore would cut the time most; more frequent backups or point-in-time recovery would cut the data loss.
Rough figures for a typical set-up, assuming the backup is good. Your own timed restore is the only real number.
Typical set-ups and what they give
With a rehearsed restore and up to about 100 GB of data. An untested restore, or a much bigger one, takes longer: the calculator above allows for both.
| Set-up | RPO | RTO | Notes |
|---|---|---|---|
| Nightly backup to another provider | Up to 24 hours | Hours | The common starting point. Cheap and safe from the main account being lost, but a day of data is at risk. |
| Hourly snapshots, same account | Up to 1 hour | 30 to 60 minutes | Quick to restore, but lost along with the account, or to ransomware with access to it. Pair with an off-site copy. |
| Point-in-time recovery (WAL or binlog archiving) | Minutes | 1 to 4 hours | Restores to any moment, including just before a bad query. The restore replays logs, so it takes longer than a snapshot. |
| Streaming replica, manual failover | Seconds | 15 to 30 minutes | Little data lost, quick recovery once someone acts. Does not protect against a bad query or deletion, which replicates too. |
| Replica with automatic failover | Seconds | 1 to 2 minutes | Managed databases (RDS Multi-AZ and similar) or Patroni on your own servers. Still needs backups for the mistakes that replicate. |
Setting targets you can keep
Start with the cost. What does an hour down cost in lost sales, refunds and staff time? And what does losing an hour of data cost: orders to re-key, customers to apologise to? Those two figures say how much a better RTO and RPO are worth.
Set them per system. The main database might need an RPO of minutes; the marketing site can live with last night's backup. One target for everything is either too expensive or too weak.
Test, then write them down. A target is only real once a restore has met it. Restore on a schedule, time each one, and keep the record: it is the evidence customers' security questionnaires and ISO 27001 auditors ask for. The free disaster recovery plan template has a place for both.
Keep one copy out of reach. At least one backup should be in a separate account or provider, and one the server itself cannot delete. Ransomware goes for the backups first. The 3-2-1 backup rule is the simple test.
Questions
What is the difference between RTO and RPO?
RPO (recovery point objective) is how much data you can afford to lose, measured back in time from the failure. RTO (recovery time objective) is how long you can afford to be down, measured forward from it. Nightly backups give an RPO of up to 24 hours, whatever the RTO.
How do I calculate RPO?
Your worst-case RPO is the gap between recovery points: the backup interval, or the replication lag if you replicate. If backups run at 02:00 and the server fails at 01:59, you lose almost 24 hours of data.
How do I calculate RTO?
Add up every step of a restore: noticing the failure, getting someone on it, building or provisioning the replacement, copying the data back, and checking the application works. The data copy is often the smallest part.
What is a good RTO and RPO for a small SaaS?
Commonly an RPO of 15 minutes to an hour and an RTO of four hours for the main database and application. Customer contracts and security questionnaires increasingly ask for both in writing, so pick figures you have tested.
How often should restores be tested?
At least every quarter for the main systems, and after any big change to them. Time each test: the measured restore time is your real RTO, and it is usually longer than the one on paper.
Are snapshots a backup?
Only partly. A snapshot in the same account and region as the server is lost with the account, a ransomware attack or a region outage. Keep at least one copy somewhere separate, and make it one that the server itself cannot delete.
When did you last test a restore?
The £250 GUARD review includes your backups: where they are, whether they restore, and how long it really takes. Book a call to start.