Almost every backup conversation ends with two abbreviations: RTO and RPO. They sound technical, but they answer two very business-like questions: how long can we be down? and how much data can we afford to lose?
If you do not set these two numbers on purpose, they get set for you, usually by whatever backup happens to be in place on the day something breaks. This article explains both with simple examples and shows how to choose them.
RTO: Recovery Time Objective
RTO is the maximum time a system or process can be unavailable before the damage becomes unacceptable. It is measured from the moment of failure to the moment the service works again.
Example: your invoicing system has an RTO of 4 hours. That means that after a failure, it must be running again within 4 hours. If recovery takes a whole day, the target was missed.
RPO: Recovery Point Objective
RPO is the maximum amount of data, measured in time, that you can afford to lose. It tells you how often data must be copied.
Example: a database has an RPO of 15 minutes. That means backups or replication must run at least every 15 minutes, so that after a failure you lose no more than the last 15 minutes of work. If you only back up once per night, your real RPO is up to 24 hours.
Remember it like this: RTO is about time to get back. RPO is about how far back you land.
Three examples from real businesses
| Business | Critical system | Sensible RTO | Sensible RPO |
|---|---|---|---|
| Web shop | Orders and payments | Under 1 hour | Minutes, almost no lost orders |
| Accounting office | Accounting software and documents | A few hours | Up to one working day |
| Manufacturing company | Production line control and ERP | Minutes to an hour | Minutes |
These are illustrations, not recommendations. Your own numbers depend on what an hour of downtime and a lost hour of data cost you.
How to set your own RTO and RPO
- List your critical systems and processes. Email, ERP, files, website, phones, production.
- Estimate the cost of downtime. Lost sales, idle staff, penalties, damaged reputation, per hour.
- Estimate the cost of lost data. How much work can be re-entered, and how much cannot be recovered at all?
- Group systems into tiers. For example: critical (minutes), important (hours), normal (a day or more).
- Match technology to each tier. Tighter targets need more advanced and more expensive solutions.
What the targets mean for technology and cost
- RPO of 24 hours can be met with nightly backups.
- RPO of minutes needs continuous replication or frequent snapshots.
- RTO of days can be met by restoring from backup onto new hardware.
- RTO of minutes needs standby systems, automatic failover or virtual machine replication to another site.
The tighter the target, the higher the price. That is why not everything deserves the same protection. Spending the most on what matters most is the whole point of having RTO and RPO.
Common mistakes
- Assuming a target without testing it. A restore that “should take two hours” often takes ten. Test and time it.
- Forgetting dependencies. An application may need a database, a license server and a network to be up before it starts.
- Keeping backups on the same network as the production systems, where ransomware can reach them.
- Setting the same target for everything and either overspending or leaving critical systems exposed.
How we can help
Alficom focuses on RTO and RPO when it designs business continuity and disaster recovery solutions: local and cloud replication, immutable backups, instant failover of virtual machines and regular recovery tests. If you do not know your numbers yet, a business impact analysis is a good first step. For what to do when an attack actually happens, read our guide to the first 60 minutes of a ransomware attack.
