3 September 2026LANTEK Computers
Two pieces of jargon that are genuinely worth learning, because between them they define what your recovery plan actually promises. Most conversations about backup skip them entirely and go straight to products, which is how businesses end up with a solution that meets a requirement nobody stated.
RPO: how much work you can afford to lose
Recovery Point Objective. It is a measure of time, looking backwards from the moment things break.
If your backup runs once a night at ten, and something fails at four the following afternoon, the most recent copy you have is from ten the previous night. Everything done during that working day is gone. Your RPO, whether anybody chose it or not, is about twenty-four hours.
So RPO answers: how much re-doing is acceptable? A business that can reconstruct a day’s invoicing from paper has a genuinely different answer to one where a day of transactions cannot be recreated at all.
The important thing is that RPO is set by backup frequency. Wanting an RPO of one hour means taking copies every hour. There is no configuration that produces a tighter RPO than the schedule allows.
RTO: how long you can be down
Recovery Time Objective. Also time, looking forwards from the break.
It is how long the business can tolerate not working before the cost becomes serious. Not how long a restore takes, which is a technical fact. How long you can stand it, which is a business decision.
RTO is where expectations and reality diverge most sharply, because the honest answer to how long a restore takes is usually much longer than anybody has assumed. Restoring a large amount of data over an ordinary business internet connection has a floor set by the speed of the link, and that floor is frequently measured in days. Nobody discovers this until they try, which is the argument for timing a real restore rather than estimating one.
The two together, with an example
Take a hypothetical business of thirty people doing professional services. Purely illustrative.
Their accounting system: losing a day of postings would mean re-entering work that exists on paper and in email. Painful, possible. Being unable to invoice for three days at month end would be much worse than losing a morning’s entries. So: RPO of a day is survivable, RTO needs to be short.
Their document store, holding client work in progress: losing a day of drafting is losing work that exists nowhere else, because nobody remembers what they wrote. But they could function for a day or two on what people have locally. So: RPO needs to be tight, RTO can be looser.
Their email: they cannot operate for an afternoon without it and they cannot afford to lose any of it. Both numbers need to be tight, which is why mail is usually the first thing to be protected differently from everything else.
The point of the exercise is that these differ per system. A single answer for the whole business is either too expensive for the unimportant things or too weak for the important ones.
How to actually set them
This is a conversation for the people who run the business, not for whoever runs the servers. IT can tell you what a given number costs. Only you can say what the outage costs.
List the systems that matter. Usually five or six, not fifty. Mail, accounting, files, the line of business application, the phones.
For each, ask two questions of the person who depends on it. If we lost everything since this morning, what would that mean in practice? And if this were unavailable for a full working day, what would stop?
Write down the answers in hours. Vague answers are the finding. Somebody saying we cannot lose anything and cannot be down at all is not stating a requirement, they are declining to make a trade-off, and the trade-off is where the cost sits.
Then ask what it would cost to meet each. This is where the numbers get revised, and that revision is the useful part. Tighter costs more, roughly continuously, and there is a point on the curve where the business decides the risk is cheaper than the control. Making that decision deliberately is the entire objective.
Then compare with what you currently have. Almost always the gap is on RTO rather than RPO, because backup frequency gets attention and restore speed does not.
Where people go wrong
Setting them from the technology. Working out what the current backup delivers and calling that the objective is reasoning backwards. The objective comes from the business and the technology is then chosen to meet it, or the gap is accepted knowingly.
Confusing RTO with restore time. RTO covers the whole outage: noticing, deciding, getting the right people, restoring, checking, and telling everybody they can work again. The restore is one part of it, and often not the longest.
Forgetting the order of recovery. Systems depend on each other. Restoring the application before the thing it authenticates against wastes hours. That sequencing question is what separates a backup from a recovery plan, and it is the subject of backup is not the same as disaster recovery.
Never testing. An RTO you have not measured is an aspiration. Restore something, time it end to end, and compare it against the number you wrote down.
Why it is worth doing at all
Because it converts an unanswerable question, are our backups good enough, into two answerable ones. And because it makes the conversation with a provider concrete: instead of asking whether they do backups, you can ask what RPO and RTO they can meet for your accounting system and what each option costs.
That is a completely different discussion, and it is one where you can tell whether the answer is any good.
What we cover is on Backup and Disaster Recovery. If you would like help putting numbers against your own systems, that is a conversation worth having before anybody quotes you anything.