RTO and RPO without the fluff: two numbers signed but never calculated

"One-hour RPO, four-hour RTO." We have heard it in meetings where nobody had ever timed how long it takes to bring a server back at that company. The two numbers travel together, they sound rigorous, they look good in the minutes — and they are almost always written backwards: instead of coming from what the business can absorb, they come from what today's backup tool happens to do. An RPO is not a technical capability. It is a promise with a price, and somebody will collect on it on the worst day of the year.

What follows is the conversation we have every time somebody shows us an inherited continuity plan: four or five questions that make the plan fall over on its own. There is almost always one of the two numbers that nobody on the committee could defend in front of an auditor, or in front of the CFO on a Tuesday morning. It is worth knowing which one before somebody external asks.

Translated into something you can actually decide

The RPO (recovery point objective) is not "how much data you lose". Nobody can make a decision out of that phrasing, because data is not measured in gigabytes when it hurts. The useful phrasing is: how much work are you willing to redo. If we go back to last night's backup, what has been done today, who redoes it, and in how many hours? With forty people at work, an eight-hour RPO is three hundred and twenty person-hours of repeated work. And that is counting only what can be redone: delivery notes get typed in again, the call that came in at half past eleven does not.

The RTO (recovery time objective) is not "how long the restore takes" either. It is how long the company can go without that service, counted from when the problem starts — not from when somebody sits down to restore — until the service is back in production and validated. Between those two ends there are four different clocks, and the only one that shows up in the plans is the restore. It is, of course, the one that matters least.

Your real RPO is the one of your last verified backup

Here is the first sleight of hand, and it is an expensive one. The backup that finished at 22:04 is not a recovery point: it is the intention of a recovery point. It becomes one once somebody has read its blocks end to end and confirmed the checksums line up. The Proxmox Backup Server documentation puts it plainly when explaining why re-verification matters: "it is recommended that you reverify all backups at least monthly, even if a previous verification was successful", because "physical drives are susceptible to damage over time, which can cause an old, working backup to become corrupted in a process known as bit rot/data degradation".

The same documentation recommends a pattern almost nobody actually has in place: a frequent verification job for new backups, plus a weekly or monthly one that re-verifies everything. If your plan promises a one-hour RPO and your hourly backups are never verified, the number you can defend is not one hour: it is the time since the last backup you know you can read end to end. The distance between those two sentences is a recovery project with the board watching.

And there is a second shift, the one an attacker introduces. Your backup frequency sets the RPO for the dumb incident: a deletion, a wrecked table, a dead disk. Your retention sets the RPO for the bad one, because the backup that helps is not the latest, it is the latest one from before they got in. Sophos's Active Adversary Report 2026, published on 24 February, put median attacker dwell time at three days and measured a median of 3.4 hours to reach the Active Directory server, 70% faster than the year before. With that shape, short retention and slow detection compound: the good copy sits behind the first one everybody looks at. It is the flip side of what we covered with the figures from the same vendor's annual ransomware report when we explained why restoring is not recovering.

The four clocks inside an RTO

The first is detect: from the moment the service starts failing until somebody knows for sure. In a clean outage that is minutes; in slow corruption or batched encryption it is hours, and sometimes a user finds it before monitoring does. The second is decide, and it is where we have seen most of the time go in recoveries that over-run. The reason is almost never technical: deciding means somebody accepting, in writing, that the last few hours of work are gone, and nobody wants to sign that at three in the morning.

The third is restore, the only one that shows up in the plans and the only one you can work out with simple arithmetic before anything happens; we do that in the next section. And the fourth is validate and reopen: checking the restored system does what it should, reprocessing the queues left half-done, reconciling with whatever kept working during the outage, and telling people they can go back to work. This is what turns a powered-on server into a running service and, on an ERP with integrations, it can take longer than the restore itself.

We have no public figure to attach to the decision clock, and we are not going to invent one. What we do have is the repeated observation that it is the one that stretches most and the only one you can shorten without spending a euro: you shorten it by writing down beforehand who decides, on what criterion, and until what time you wait. In our experience, a plan that names one person and a hard deadline cuts more RTO than doubling your bandwidth.

The arithmetic almost nobody runs

Take the volume you would have to restore and the link it has to travel through. The maths is primary-school level and it dismantles more plans than any audit:

The uncomfortable conclusion of that simple sum is that an RTO is not decided: it is measured. And it gets measured once a year with a real stopwatch, restoring something real. No number should be signed that has not been timed in a rehearsal, because on the day it fails there is no room to discover that the paper said four hours and the array does 180 MB/s.

The number missing from almost every plan

RTO and RPO describe a binary world: the service is either up or down. The reality of a recovery is a long stretch of being half-up, and that stretch has no number assigned to it in any plan we have reviewed. What does "running at half speed" mean in your company? Can you invoice by hand for a day? Can you receive goods without the ERP and enter them later? Does the workshop stop, or does the workshop carry on while the back office is what halts?

Out of that conversation comes the thing that actually drives a recovery: the order. What comes back first, what comes back next, and what can wait until tomorrow. If the order is not written down, it gets decided by whoever shouts loudest down the phone, who is almost never the person with the most critical system. Writing three lines of priorities costs one meeting and saves the two worst hours of the incident. It is the same exercise we proposed after July's Microsoft 365 outage, when the decision was not how to fix it but how to keep working in the meantime.

When you should not lower the number

Selling continuity is easy: you can always propose a smaller number and charge for it. We think it is more honest to say when not to. Dropping an RPO from twenty-four hours to fifteen minutes multiplies storage and link costs and, in many companies, changes nothing, because the RTO is what hurts: losing fifteen minutes of data hardly matters if you are going to be down for two days. Applying the ERP's RPO to the file server is another expensive classic; and buying synchronous replication for a system used from nine to six is paying insurance against a risk you do not have.

There is also a part of the number that is not yours. If the service lives in a public cloud, your RTO includes the recovery time of a provider you cannot phone and cannot negotiate priority with: we went through it with a clock in hand during July's AWS CloudFront outage. And if your answer to all of this is "that is what backups are for", it is worth looking now and then at what happens when the deletion reaches the backup too: that is the scenario that turns a one-hour RPO into a spreadsheet rebuilt by hand.

The five lines we do write down

The question we ask first

When we review a continuity plan we do not start with technology. We start with this: when did you last restore something for real, and how long did it take? If the answer is a date and a number, the rest of the conversation is fine-tuning. If the answer is "the backups are fine, they do not throw errors", then you do not have an RTO: you have an expectation, and expectations do not restore.

Sources: the monthly re-verification recommendation, the literal quotes on bit rot and the verification-job pattern — Proxmox Backup Server maintenance documentation; the --live-restore option and its literal description — Proxmox VE qmrestore manual page; median attacker dwell time of three days and Active Directory reached within hours — Sophos Active Adversary Report 2026 (February 2026). The restore-time figures are direct arithmetic from nominal bandwidth and are presented as a lower bound, not an estimate. Cover image: "Departure board at Hackerbrücke S-Bahn station in München", Robert von Oliva, CC0, via Wikimedia Commons.