Glossary · simply explained

RTO & RPO

RTO says how fast a system must run again; RPO how much data loss is bearable — the two levers of any DR planning.

RTO and RPO are the two metrics every contingency and backup plan aligns to: the recovery time objective (RTO) defines how long a system may stand still after an outage at most. The recovery point objective (RPO) defines how old the last recoverable data state may be — that is, how much work is lost in the worst case.

Both values are business decisions, not IT values: they derive from the costs of downtime and data loss per process — and then determine which backup frequency, replication and DR strategy is technically necessary and economically justifiable.

What the two metrics mean

The RTO clock runs from the outage: detection, decision, restore, test, release — everything must fit into the window. An RTO of four hours does not mean four hours of restore time but four hours to a usable system. The RPO looks back: with an RPO of one hour, the last backup may be at most one hour old — everything after is potentially lost.

Both values scale costs inversely to tolerance: RPO near zero demands synchronous replication instead of nightly backups; RTO near zero demands running standby systems instead of restoring from backup. That is why RTO and RPO are tiered per application — not set flat for the whole company.

Typical tiering in practice

Critical core systems (ERP, production control): RTO minutes to a few hours, RPO minutes — replication and standby.
Important business applications: RTO a few hours to a day, RPO hours — frequent backups or snapshots.
Non-critical systems (archive, test): RTO days, RPO 24 hours — classic daily backup.
Measure instead of hope: restore tests prove the actual time (RTA) against the target.

Frequently asked questions about RTO & RPO

Who sets RTO and RPO — IT or the business?

The business quantifies the damage costs per hour of downtime and per hour of data loss; IT translates the targets into technology and names the costs. The decision is a business trade-off — in the BCM context usually via a business impact analysis.

What is the difference between RTO and RTA?

The RTO is the target, the recovery time actual the measured result of a test or real event. If the two diverge, the plan is waste paper — which is why regular recovery exercises with time measurement belong to any serious DR planning.

How do you achieve an RPO near zero?

With synchronous or near-synchronous replication to a second system — every transaction exists twice before it is acknowledged. That costs infrastructure, bandwidth and, with synchronous replication, latency; it only pays off for data whose loss is truly unbearable.

Why should RTO/RPO be tiered per system?

Because flat values are either too expensive or too risky: a company-wide RTO of one hour for all systems multiplies DR costs; 24 hours for everything paralyses critical processes. Tiering by business criticality directs budget to where downtime is genuinely expensive.

What influence does the network have on RTO and RPO?

A direct one: replication needs bandwidth and stable latency — the RPO hangs on the line between sites. And in recovery, the network switchover (DNS, routing, access) co-determines when users reach the system again — it belongs in every RTO calculation.