RPO and RTO: how to choose the numbers instead of copying them

The two numbers, without the jargon

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. (Some frameworks, NIST among them, call that whole clock the maximum tolerable downtime and reserve RTO for the technical restore; 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 actual recovery is a hardware order. That estate has almost no data loss and a recovery time measured in weeks. It is a more common combination than it sounds.

Why the last few minutes cost the most

Both curves are steep at the left-hand end, and understanding why makes the budget conversation much shorter.

Illustrative industry tiers to show the shape of the curve, not a commitment; 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. Anyone who asks for near-zero on everything has usually not been shown that step.

Which is the argument for tiering, and it is the single most useful thing in this article.

Tier the systems, then price each tier

Setting one target for the whole estate guarantees one of two outcomes: you pay for speed on systems that did not need it, or you accept slow recovery on the system that pays the salaries. 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 actually happens in the first four hours it is unavailable, and what happens if we lose the last hour of data. Not what it would feel like: what stops, who cannot work, what cannot be invoiced, and what is contractually or legally required.

Three tiers is almost always enough:

Two traps in this exercise. 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.

What actually determines RTO

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 (in an Active Directory estate they live on the same servers), 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 estates 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. This is the classic reason a technically successful failover is a business failure.

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

Data validation. Recovering is not finishing. 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.

The test is the deliverable

Everything above is a plan. A plan that has never been executed has an unknown RTO, and unknown numbers do not belong in 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 against the tier target, honestly, 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 always overruns. That is the point of it: the first test is how you find out what your RTO really is, and it is almost never the number in the document.

Backup is not disaster recovery

These get used interchangeably and they solve different problems.

You need both, and backup does not become disaster recovery by being stored off-site. The question that separates them is simple: if this building were unavailable tomorrow morning, what would the workload run on? If the answer is “we would order hardware”, you have backup.

One thing backup must have on its own account: an immutable copy that cannot be deleted by an administrator account. Modern ransomware goes looking for the backup system first, and a backup that can be encrypted along with everything else has an RPO of infinity at exactly the moment it matters.

What we do

Disaster recovery as a service from Eurokommerz starts with the tiering exercise above, not with a product: which systems sit in which tier, what each tier costs, and the dependency order written down. Recovery targets are then agreed per tier in the SLA, tested on a schedule, and the test results are yours in writing.

The recovery site is Tier-3 EU capacity through our engineering partner Vixen.UNO’s data-centre partner Baltneta, and the engineering is Vixen.UNO’s, all under one European contract with us. If you are not sure which tier anything belongs in, that is what the first conversation is for, and it is free.

FAQ