The two questions they answer
When a system goes down, there are two questions. How soon must it be working again? And how much data can we afford to lose? RTO and RPO are the answers, written down and decided before it happens.
RTO (Recovery Time Objective): the maximum time within which a service must be back in operation after an interruption.
RPO (Recovery Point Objective): the maximum amount of data you are prepared to lose, expressed as time: how far back the last usable restore point can be.
An example: if the ERP has an RPO of 4 hours and an RTO of 8 hours, in the event of a failure you are prepared to lose at most the last four hours of work, and the system must be working again within eight hours of the interruption.
RTO looks forward, RPO looks back
The easiest way to keep them apart is to picture them on a timeline, with the incident in the middle. RPO measures backwards: up to what point the data is safe. RTO measures forwards: when work can resume.
They are independent of each other. A system can have a very tight RPO and a loose RTO (the data is replicated almost in real time, but getting the application back up takes a working day), or the other way round.
| RPO | RTO | |
|---|---|---|
| Question | How much data can I lose? | How long can I be down? |
| Direction | From the failure backwards | From the failure forwards |
| Depends on | Frequency and type of copies | Procedures, recovery infrastructure, people |
| Improved by | More frequent backups, replication, snapshots | Automation, standby environments, tested procedures |
How to define them: from processes, not servers
The most common mistake is to start from the technology: “the backup runs at night, so the RPO is 24 hours”. That describes what you have, not what you need. The right way is the reverse: start from the business processes and ask the people who run them what it costs when they stop.
- List the critical processes: invoicing, production, logistics, customer service. For each one, the systems it depends on.
- Estimate the impact of downtime over time: what happens after an hour, after half a day, after three days. This is the core of a business impact analysis. For the financial side you can start from the downtime cost simulator.
- Estimate the impact of data loss: how much work would have to be redone, and whether it can be redone at all. Orders received by email can be recovered; till transactions or production measurements often cannot.
- Decide the values together with the business: RTO and RPO are economic choices, not technical ones. The tighter they are, the more expensive the solution needed to guarantee them.
- Only then choose the technology: backup frequency, replication, recovery environments, supplier contracts.
Not all systems are equal
Giving everything the same RTO is the quickest way to overspend on secondary systems and underspend on critical ones. Systems are usually grouped into tiers. The values below only illustrate what a classification looks like and are not a standard: they must be derived from an analysis of your own business.
| Level | Examples | RTO | RPO |
|---|---|---|---|
| Critical | ERP, e-commerce, production systems | A few hours | Minutes |
| Important | Email, shared files, CRM | One working day | A few hours |
| Non-urgent | Archives, intranet, test environments | A few days | 24 hours or more |
Watch out for dependencies: the “critical” ERP will not restart until the services it needs are back, such as authentication, DNS, network and licences. Their RTO cannot be looser than that of the systems that use them.
An untested RTO is an assumption
The number written in the plan only counts if it has been measured. And the real RTO covers much more than the time it takes to copy the data back: noticing the problem, deciding to restore, retrieving the credentials, preparing the environment, restoring, checking that everything works, notifying users.
That is why restore tests must be planned and recorded, with the real times. In the story The Friday evening the files changed their names we show what difference it makes when the last test was only a few weeks old: the time needed to get the ERP back up was already known.
- backups fail without anyone receiving an alert;
- nobody has ever restored an entire system, only individual files;
- the copies can be reached with the same credentials as the servers, and an attack can delete them along with the originals;
- data in cloud services, for example email and documents in Microsoft 365, has no independent backup.
The most common mistakes
- Numbers chosen by IT alone. Without the business, RTO and RPO describe the infrastructure, not the risk.
- One value for everything. Either you pay for the top level everywhere, or what matters ends up poorly protected.
- Forgetting ransomware. A hardware failure is fixed with the last copy; an attack may have hit the copies too, or have started weeks earlier. You need at least one isolated or immutable copy: we cover this in the guide on the 3-2-1 backup rule.
- Never reviewing them. New systems, new sites and new processes change priorities: RTO and RPO must be reviewed periodically and whenever something significant changes.
In short
RPO tells you how much data you can lose, RTO how long you can be down. They are set on the basis of the cost of downtime, vary by criticality and only count if measured with real restore tests.