Ask what a disaster recovery design should look like and you will get an architecture. Ask what it should cost and you will get a range so wide it is useless. Both answers are downstream of two numbers that are usually never set properly, which is why the architecture and the price both float.
They are not difficult numbers. They are just uncomfortable ones, because setting them means admitting what the business can actually tolerate.
The Two Numbers, Precisely
RPO — recovery point objective — is how much data you can afford to lose, measured in time. It looks backwards from the moment of the incident. An RPO of one hour means that when you come back up, you are working from a copy that is at most one hour old, and everything after that point is gone.
RTO — recovery time objective — is how long you can afford to be down. It looks forwards from the moment of the incident to the moment the business is working again.
They are independent. An estate can have a fifteen-minute RPO and a two-day RTO: the data is nearly current, but nobody has anywhere to run it. That combination is more common than it sounds, and it is what “we replicate to a second site” often means in practice.
What They Mean on an Actual Tuesday
Say the incident starts at 09:40. With an RPO of one hour, the last consistent point is 08:40, so the work between 08:40 and 09:40 has to be redone or written off — which for most businesses means invoices, orders and conversations that a person now has to reconstruct from memory and an inbox.
With an RTO of four hours, the business is working again by 13:40. Not “the servers are up” by 13:40 — working, with staff logged in and able to do the job.
Those two sentences, per system, are what a DR plan is. Everything else is implementation.
How to Set Them Without Guessing
Asking the business “how long can you be down?” produces the answer “we can’t be down”. It is a bad question because it has no cost attached. These are better:
- What is the first thing that stops? Not the first system — the first activity a person cannot do.
- At what point does someone outside notice? Customers, suppliers, a regulator. That moment is usually much earlier than the internal estimate.
- At what point does it cost money that does not come back? A delayed order is recoverable; a cancelled one is not.
- What would we have to redo by hand? This one sets the RPO, and it is the question that makes “we’d lose a day’s work” concrete — a day of whose work, redone from what?
The answers rarely come out even across an estate. That is the point: they are supposed to differ, and a design that treats every workload the same is either overspending on most of it or underprotecting the part that matters.
What Each Band Forces to Exist
This is where the numbers turn into money. The cost of a recovery target is almost entirely the cost of what has to be running already rather than waiting to be started:
| Tier | RPO | RTO | What that forces to exist | Relative cost |
|---|---|---|---|---|
| Critical | Seconds to 15 min | Under 1 hour | Replicas continuously current; compute reserved and licensed on the far side; addressing, firewall rules and load balancers pre-staged; failover rehearsed, not theorised | Highest |
| Important | 1 to 4 hours | 4 to 12 hours | Replicas current but powered off; compute available on demand; a documented, tested boot order | Middle |
| Standard | 24 hours | 1 to 3 days | Backup-driven rebuild onto whatever is available, with the restore arithmetic done in advance | Low |
| Deferred | Whatever backup gives | When it gets to the top of the list | Nothing beyond retention | Near zero |
The jump that surprises people is between Important and Critical. Shortening an RTO from eight hours to one does not make the recovery a bit faster — it changes what you are buying, from “a copy we can boot” to “a second environment that is already up”. Those are different products at different prices, and the line between them is roughly where human decision-making stops fitting in the window.
Why “Zero and Zero” Is Not an Answer
Everyone’s first answer is zero data loss and no downtime. It is the right instinct and the wrong specification, for two reasons.
The first is cost. A genuine zero-RTO design means the second environment is running the workload now, with licences, capacity and a tested failover path — and if you apply that to a whole estate, the DR bill approaches the production bill. Budgets do not survive that, so the plan gets cut later, unevenly, usually by whoever is holding the invoice rather than by whoever understands the systems.
The second is that zero is sometimes the wrong goal. A near-zero RPO replicates faithfully — including the bad migration, the corrupted table and the ransomware. If the only copy you have is current to within thirty seconds, then thirty seconds after the damage, your recovery point contains the damage. That is why retention and replication are separate purchases, and why the serious designs have both: replication for the site-level event, retained points for the self-inflicted one.
RTO Is Not the Restore Time
The most common planning error we see is measuring the RTO as the technical recovery step alone. The clock starts when the incident starts, and the technical work is one segment of it:
- Detection. How long before someone knows this is an incident rather than a blip.
- Declaration. The decision to fail over, which is a business decision with a cost attached. Failing over is disruptive and sometimes irreversible, so people hesitate — and the hesitation is inside your RTO whether you planned for it or not. Decide in advance who is allowed to make that call, and on what evidence.
- Execution. The part everybody plans for.
- Verification. Confirming the applications actually work, in the right order, before the business is told it can resume.
- Return. Coming back to the primary site afterwards, which is a second project and is almost never rehearsed.
If your stated RTO is four hours and detection plus declaration routinely takes ninety minutes, the technical target is two and a half, not four. Writing that down changes designs.
Set Them Per Workload, Not Per Estate
A single pair of numbers for the whole estate is the main reason DR budgets collapse. The finance system, the file shares and the dev environment do not share a tolerance, and pretending they do means paying for the strictest across all of them or exposing the most important to the loosest.
The practical version is a short classification — critical, important, standard — applied per application rather than per virtual machine, with the dependencies named. A database at tier one behind an application at tier three recovers into nothing. Part four of this series is entirely about that exercise, including what to leave out deliberately.
Make Them Survive the Meeting
Two numbers per application, agreed with whoever owns the business consequence, written somewhere that is not a slide. Review them when the business changes shape, not annually out of habit — a new product line or a new regulator moves them far more than a year does.
Then test whether you actually meet them, because an untested target is a hope with a number on it. That is the last post in this series, and it is the one that most often changes people’s minds about their own plan.
Working Out Your Own Numbers
The DR planner asks nine questions and shows you what your recovery target implies: the replica storage it needs, how long the first seed takes over your uplink, the bandwidth continuous replication consumes afterwards, and — the part relevant here — what your RTO choice forces to be running already rather than waiting to be started. No prices, and no email gate on the numbers.
If you would rather talk it through, our DRaaS service page sets out the shape of the engagement, and telling us what you run gets you an assessment call — including the version where we tell you your current targets are already fine.
Next in the series: what to protect, and what to leave — a worked classification of a 40-VM estate.
