RTO and RPO: what they are, the difference, and how to define each one
RTO is how long until you are back; RPO is how much data you accept losing. See the meaning, the difference, and how to set both numbers in your infrastructure.
Optidata
RTO (Recovery Time Objective) is the maximum acceptable time to restore a system after a failure. RPO (Recovery Point Objective) is the maximum amount of data you accept losing, measured in time. In short: RTO is how long until you are back, RPO is how much data you can lose.
Every continuity plan comes down, in the end, to two numbers. When a system goes down, the board’s first question is “how long until we are back?”. The second, once the dust settles, is “did we lose data?”. Knowing what RTO and RPO are, and having defined both before the incident, is what separates a calm answer from a crisis meeting. This article explains each one, shows the difference in a single sentence, and teaches you to set the right numbers for your operation.
What RTO is
RTO, short for Recovery Time Objective, is the maximum time your company accepts having a system down before restoring it. It is the answer to the question “from the moment of failure, how long do we have to come back?”.
RTO is a business decision before it is a technical one. It defines the budget and the architecture you will need. An RTO of a few minutes requires active redundancy and automatic failover, which costs more. An RTO of a full day allows a simpler and cheaper strategy. The right number is not the smallest possible, it is the one that balances the cost of preventing against the cost of being down.
What RPO is
RPO, short for Recovery Point Objective, is the maximum amount of data your company accepts losing in case of failure, measured in time. It answers the question “how far back in the past can we go without serious harm?”.
In practice, RPO defines the frequency of your backups and replications. If you accept losing at most five minutes of data, you need to replicate every five minutes or less. If you accept losing a day, a daily backup solves it. RPO translates the value of your data into a protection cadence: the more critical the data, the lower the RPO, and the more frequent the copy.
The difference in one sentence
The confusion between the two disappears with one sentence: RTO is about system downtime, RPO is about the amount of data lost.
An example makes it clear. Imagine a database fails at 10:12. The last backup was at 10:00. The system comes back at 11:00. In that case, the real RPO was 12 minutes, because the data generated between 10:00 and 10:12 was lost. And the real RTO was 48 minutes, the time between the failure and the return. One measures the hole in the past, the other measures the duration of the interruption. You need both, because optimizing only one leaves the other exposed.
How to define each number in your business
There is no single RTO and RPO for the whole company. Each system has a criticality, and trying to give the same number to all of them is waste on one side and risk on the other. The path is to classify systems by impact and assign objectives to each class.
The table below shows a common way to organize this. The values are illustrative and serve to help you reason about your own ranges, not as a fixed benchmark.
| Criticality | Examples | Typical RTO | Typical RPO |
|---|---|---|---|
| Critical | ERP, e-commerce checkout, transactional core | Minutes to 1 hour | Seconds to minutes |
| Important | CRM, BI, internal support systems | 2 to 8 hours | Up to 1 hour |
| Secondary | Files, dev and test environments, reports | 24 hours or more | 24 hours |
The logic is direct. The more an interruption of that system hurts revenue, operations, or reputation, the shorter the RTO and RPO need to be, and the more the company needs to invest in redundancy to sustain them. Support systems tolerate longer times, and spending on instant failover for them is throwing money away.
The cost of each hour of RTO
Defining RTO without knowing the cost of each hour down is deciding in the dark. The number that justifies the investment in recovery is the downtime cost, that is, how much your company loses per hour of unavailable system.
The basic calculation adds lost revenue, the cost of the idle team, and the impact of reputation and fines, divided by operating time. A simple example shows the logic: if your operation makes, on average, twenty thousand per hour and a failure takes the system down for three hours, the interruption cost sixty thousand in revenue alone, not counting the idle team and reputation. With that figure in hand, the RTO decision stops being opinion. If each hour down costs a high amount, a short RTO pays for itself; if the cost per hour is low, a more relaxed RTO is the rational choice. This is the calculation that turns continuity from “best practice” into a defensible budget decision.
Common mistakes when promising RTO and RPO
Four mistakes show up frequently when companies define these numbers.
The first is promising an RTO that was never tested. A four-hour RTO in the contract means nothing if the company never ran a real restore to measure whether it can meet it. RTO on paper is a hypothesis; tested RTO is a commitment.
The second is confusing the two objectives and ending up protecting only the time, forgetting the data, or the other way around. Both need separate attention.
The third is applying the same number to everything. Giving a minutes-long RTO to a secondary reporting system wastes money for nothing; giving a one-day RTO to the transactional core is taking on a risk the board would not approve if it understood it.
The fourth is treating RTO and RPO as fixed numbers forever. As the operation grows and the criticality of systems changes, the objectives need to be reviewed. A number set three years ago may be dangerously outdated today.
Frequently asked questions
What is RTO? It is the maximum acceptable time to restore a system after a failure, that is, how long until you are operating again.
What is RPO? It is the maximum amount of data you accept losing in case of failure, measured in time. It defines the frequency of backup and replication.
What is the difference between RTO and RPO? RTO measures system downtime; RPO measures the amount of data lost. One deals with the duration of the interruption, the other with how far back you go in the past.
What is a good RTO? There is no universal value. A good RTO is the one that balances the cost of keeping redundancy against the cost of each hour down for that specific system. For the critical core, it is usually minutes to an hour; for support systems, hours.
Is a 4-hour RTO realistic? It can be, as long as the architecture supports it and the company has tested the restore within that window. Without a real test, any RTO is just an unverified promise.
Optidata designs RTO and RPO with you and includes DR in two regions. Talk to a specialist.