RPO and RTO: what they mean and how to set them for each system

What RPO and RTO mean

Both describe the same incident from two sides.

RPO (recovery point objective) is how far back in time you are willing to go. It is the amount of work you accept losing. If your last usable copy is from an hour ago, everything entered in that hour is gone and has to be re-created from paper, email or memory. RPO is decided by how often data is copied.

RTO (recovery time objective) is how long the business waits, from the moment the incident starts until people are working again. (NIST’s contingency planning guide, SP 800-34 Rev. 1, calls that whole clock the maximum tolerable downtime and uses RTO for how long each system may stay unavailable within it; whichever term you use, measure the whole clock.) RTO is decided by how quickly something can be made to run, not by how quickly the data can be found.

They are independent, and confusing them produces expensive mistakes. You can have an excellent RPO and a terrible RTO: replicated every five minutes to a second site, but with no server there to start it on, so the recovery waits for a hardware order. Such an environment loses almost no data, but its recovery time is set by how long new servers take to arrive and be built.

Why cost rises steeply as RPO and RTO approach zero

Cost climbs steeply as either target approaches zero, for the reasons in the table.

Illustrative industry tiers for the recovery point, to show the shape of the curve, not a commitment; restoring from a nightly backup can still take days, and the numbers in your SLA come from your own impact analysis

The step that costs is the one from “a few hours” to “minutes”, because that is where you stop buying storage and start buying a second running environment. When near-zero targets are requested for every system, this step has usually not been priced yet.

Tier the systems, then price each tier

One target for all systems leads to one of two outcomes: you pay for fast recovery on systems that do not need it, or you accept slow recovery for the systems that bring in the revenue. Tiering avoids both, and the exercise is short.

Sit down with the people who own the processes and ask two questions about each system: what happens in the first four hours it is unavailable, and what happens if the last hour of data is lost. The answers should be concrete: what stops, who cannot work, what cannot be invoiced, and what is contractually or legally required. Our guide to the business impact analysis for IT describes the full method, from impact over time to maximum tolerable downtime.

Three tiers is almost always enough:

The exercise has two common pitfalls. First, every department believes its own system is critical, which is why the question is about consequences rather than importance. Second, authentication and DNS belong in the top tier even though no department claims them, because nothing else recovers until they are up.

Our disaster recovery service starts with this exercise, and its output is a continuity plan with target RPO and RTO for each tier. Write to us with the systems you would put in the top tier; the first call is free of charge.

What the RTO includes besides the restore

RTO is the number that gets estimated optimistically, because people time the restore and forget everything around it. The real clock includes:

Detection and decision. Somebody has to notice, and somebody with authority has to declare a disaster and start the plan. Out of hours this alone is regularly the longest single item, and it is almost never in the estimate.

The dependency order. Systems come back in a sequence: directory, authentication and DNS together (they often run together on the domain controllers), then databases, then application servers, then the integrations between them. Starting the ERP system before its authentication source is available does not work, and finding this out during a real incident costs hours. Most organisations have never written the order down.

Networking and name resolution. The application is running at the second site and nobody can reach it, because DNS still points at the primary, the TTL is 24 hours, or the VPN routes are configured for one location only. Users then cannot work even though the failover itself has succeeded.

People. Who has the credentials, who can approve the switch, and what happens if that person is on a plane. If only one engineer can execute the runbook, the RTO depends on that engineer’s availability.

Data validation. A recovered system is not yet ready for use: someone has to confirm the data is consistent before people start entering more on top of it, and for a transactional system that check is not instant.

Testing the recovery plan

Everything above is a plan. A plan that has never been executed has an unknown RTO, and an unknown RTO should not be written into an SLA.

A test that is worth doing has four properties. It runs the workload rather than confirming that files exist: the application starts and someone logs in and does a transaction. It is timed in full against the tier target, from declaration to working. It is run by whoever is on shift, not by the person who designed it. And it produces a written result with what broke and what the measured time was, which, for organisations with supply-chain or continuity obligations, is also the evidence an auditor or a customer will eventually ask for.

Twice a year for critical systems is a reasonable rhythm, and the first test usually overruns its target. The purpose of the first test is to find out the real RTO, which is almost never the number in the document.

We run scheduled test restores as part of our disaster recovery service, with a report after each on what came up, how fast and what to fix. Tell us when you last ran a restore test and how long it took.

What backup recovers and what disaster recovery recovers

These get used interchangeably and they solve different problems.

You need both, and backup does not become disaster recovery by being stored off-site. To tell them apart, ask what the workloads would run on if this building were unavailable tomorrow morning. If the answer is “we would order hardware”, you have backup.

Backup itself needs an immutable copy that cannot be deleted by an administrator account. Ransomware operators now go after the backup system deliberately (in a 2024 Sophos survey of organisations hit by ransomware, 94 per cent said the attackers had tried to compromise their backups), and a backup that can be encrypted along with everything else provides no recovery point when it is needed.

What we do

Our disaster recovery service runs the recovery site for the systems that need one: replication to the Tier III data centres of Vixen.UNO’s data-centre partner Baltneta in Lithuania, with targets defined per system tier during the assessment and fixed in the SLA. Our engineering partner Vixen.UNO designs, sets up and supports it, under one European contract with Eurokommerz. If you are not sure which tier a system belongs in, that is what the free first call is for.

FAQ