Ask three providers for a disaster recovery quote and you will get three numbers that are not comparable, because you have asked for three different products. The word covers replication, backup and high availability, and the gap between them is most of the price.
What Are You Actually Buying?
Start by separating the three things the word is doing, because almost every bad DR purchase comes from buying one while needing another.
- Backup keeps a copy of your data that you can go back to. It answers can I get the file back, and from when?
- High availability keeps a service running through the failure of one component. It answers can this survive a dead host without anyone noticing?
- Disaster recovery keeps a second environment that can take over. It answers can the business trade on Tuesday if the room is gone?
Those are not three grades of the same thing. They are three different purchases, and an estate usually needs some of each.
What Backup Is For, and Where It Stops
Backup is the one everybody already has, which is why it is also the one most often mistaken for a DR plan. It is excellent at the thing it does: a file deleted on Thursday, a database corrupted by a bad migration, a mailbox someone cleared out, an encrypted server you need to rebuild from a known-clean point.
Where it stops is time. A backup is data at rest somewhere else, and turning it back into a running business means provisioning somewhere to put it, restoring it over a network, reconfiguring what the restore did not carry, and then testing all of it with people waiting.
That is not a criticism of backup — it is what backup is. The mistake is counting it as your recovery plan and discovering the restore arithmetic during the incident rather than before it. Part two of this series does that arithmetic properly, because the number surprises people.
What High Availability Is For
High availability operates inside one environment. A host dies, and the workload comes up elsewhere in the same cluster or pool; a disk fails and the array carries on. Done well, nobody outside the operations team learns it happened.
What it does not survive is the environment going away — the site, the network into it, the storage platform, or an administrative event such as ransomware or a bad change propagating everywhere at once. High availability replicates your problem faithfully to the standby node. That is the point at which you need somewhere else entirely.
So What Is DRaaS?
Disaster recovery as a service is a second environment, kept current, that you can switch to. Your virtual machines replicate from wherever they run now into a provider’s platform, continuously, and sit there ready rather than sitting there as a filesystem.
Three properties do the work, and they are the ones worth testing in any quote you are given:
- Replication is continuous and agentless. Changes ship as they happen rather than once a night, and nothing has to be installed inside the guests to make it work — which matters once you count how many machines are in scope.
- The replicas can boot. They are virtual machines on the far side, not an archive of one. That is the whole difference from backup, and it is what makes the next point possible.
- You can test it without a disaster. Bring the replicas up in an isolated network, confirm the application actually comes back, shut them down. If a provider cannot offer that, you are buying a promise rather than a capability.
That third one is the one we would push hardest on. An untested DR plan is a spreadsheet, and part six of this series is entirely about the drill.
What DRaaS Is Not
Four things it gets sold as, and is not:
- It is not a backup replacement. Replication copies your mistakes as faithfully as your work. If a database is corrupted at 14:00, a continuously replicated copy is corrupt by 14:01. You need retained restore points as well, which is why the two appear on the same quote and should not be collapsed into one line.
- It is not automatic. Failover is a decision someone makes, with consequences — failing back afterwards is the harder half, and it is the part nobody demos.
- It is not for every machine. Replicating the dev box, the old file server and the print queue is how a DR budget dies without protecting anything that matters. Part four is a worked classification of a real estate.
- It is not a compliance checkbox. It is a running cost that buys a specific recovery time. If nobody can say what that time needs to be, the project has not started yet.
The Two Numbers That Decide Everything
Every honest DR conversation reduces to two figures, per workload:
- RPO — how much data you can afford to lose, measured in time. Fifteen minutes? An hour? Yesterday?
- RTO — how long you can afford to be down before it hurts in a way that shows up on the P&L.
They are the only two inputs that move the price meaningfully, because they decide how much has to be running already rather than waiting to be started. Everyone’s instinct is to answer “zero and zero”, and the cost of that answer is what makes people revise it. Part three is entirely about those two numbers and what each choice actually costs.
Who Actually Needs This
You probably need DRaaS if an outage of a working day would cost real money or real customers, if your systems run in one place today, or if you have contractual or regulatory recovery commitments you could not currently evidence.
You probably do not if your workloads already run across two sites with the data in both, if everything that matters is SaaS someone else operates, or if the honest answer to “how long could you be down” is “a few days, awkwardly”. In that last case, buy better backup and spend the difference elsewhere. We would rather say that now than sell you a replication platform you will cancel in a year.
What We Don’t Do
We do not quote DRaaS from a web form. Used storage, daily change rate and which machines are genuinely critical are the three inputs that move the monthly figure most, and all three are guesses until someone has looked at the estate — so a number produced before that gets revised in the first meeting, which is a poor start for a service whose entire pitch is rigour.
What we will do for free is the arithmetic you can check yourself. The DR planner takes nine answers and shows you four things: how much replica storage your estate implies, how long the first seed takes over your uplink, how much bandwidth continuous replication consumes every day afterwards, and what your RTO target forces to be running already. No prices, no email gate on the numbers.
Most people find the seed time is the figure that reframes the project.
Next in the series: backup is not disaster recovery — with the restore arithmetic written out.
If you would rather just talk it through, our DRaaS service page has the shape of the engagement, and telling us what you run gets you an assessment call — including the version where we tell you that better backup is the right purchase.
