RTO and RPO explained simply (and how to set yours)

July 15, 2026 · 4 min read · SOVALYX Technologies

RTO (Recovery Time Objective) is the maximum outage duration you accept for a system: "how long without the application?". RPO (Recovery Point Objective) is the maximum age of the last usable backup: "how much work lost?". Both are set with the business, application by application — never as a single company-wide number.

RTO and RPO: the definitions

RTO: how long without the system?

RTO is the maximum time between the incident and the return to acceptable operation. An RTO of four hours means: at most four hours after the outage, the application must be serving users again. The main lever is architecture — standby servers, replication, automated failover procedures — and it is verified by timing a real failover.

RPO: how much data lost?

RPO is also measured in time, but it looks backwards: it is the maximum acceptable gap between the last restore point and the moment of the incident. An RPO of one hour means: at worst, one hour of work has to be redone. The main lever is backup frequency, up to continuous replication for a near-zero RPO.

The difference in one sentence

RTO measures tolerable downtime looking forward; RPO measures tolerable data loss looking backward. The two are independent: a system may tolerate a full day of downtime but no data loss at all (long RTO, short RPO), and the reverse exists too.

Examples by application type

The orders of magnitude below are illustrative and should be adjusted to your context — they are not standards:

The lesson of this table: a company does not have one RTO and one RPO — it has one pair per application. In practice, three criticality tiers are almost always enough to classify the whole estate, and they stop you paying "payments-grade" money for "archive-grade" systems.

The method for setting yours with the business

1. Inventory critical processes, not servers: taking payments, producing, shipping, paying salaries. Applications come second, as supports for those processes.
2. Ask the business about real tolerance: "after how long does an outage become serious?", "what would losing the last four hours of entries mean?". The first answers — "zero downtime, zero loss" — correct themselves once the cost of each tier is introduced.
3. Translate into RTO and RPO per application, following dependencies: the point-of-sale application is useless if the database, the network or the directory are not covered by at least equivalent targets.
4. Confront each tier with its cost, set against the calculated cost of downtime — the cost of one hour of downtime method provides the figure to put on the other side of the scale.
5. Decide, document and have management sign off: an RTO is a business decision that commits budget, not a technical parameter.
6. Verify through tests that the targets are actually met. An RTO that has never been tested is a hypothesis, not an objective.

The link with cost

Reducing an RTO or RPO gets more expensive in a non-linear way. Going from a day to a few hours is often achieved with sound backups and clear procedures. Going from a few hours to a few minutes requires continuous replication, a properly sized standby infrastructure and automated failover. Aiming for near-zero demands active redundant architectures whose cost is justified only for a minority of applications.

That is why tiering is the single most profitable decision of the whole exercise: it concentrates investment where downtime genuinely hurts. These targets then become the measurable commitments of your SLA, the specification of your disaster recovery plan — and the yardstick for judging any recovery infrastructure worth the name.

Summary table

🧰 The companion tool: RTO/RPO simulator: what level of DR does your application need? — free · 2 minutes.

Reviewed and optimised by AI.