Almost every estate we are asked to look at already has backup, and almost every one of them describes it as the disaster recovery plan. That is not carelessness. Backup is the thing you buy first, it has rescued everyone at least once, and nothing in a backup console tells you what it cannot do.
What it cannot do is time. That is the whole of the difference, and it is measurable in advance.
Two Different Questions
Backup answers can I get the file back, and from when? Disaster recovery answers can the business trade on Tuesday?
Those questions have different owners. The first belongs to whoever runs the systems. The second belongs to whoever answers for revenue, and it is a question about elapsed hours, not about whether a copy exists. An estate can have perfect backups and still be shut for three days.
What Backup Is Genuinely Good At
It is worth being precise about this, because the point is not that backup is weak. For a large class of incidents it is exactly the right tool and a replication platform would be overkill:
- A file or folder deleted on Thursday that someone wants back on Friday.
- A database corrupted by a bad migration, where you want a known-good point rather than a running copy of the damage.
- A ransomware event where the value is in the clean point, not the current one.
- Retention you are required to hold — seven years of something, which no replication product is designed to keep.
Notice what those have in common: the environment still exists. There is a working platform to restore onto, and the clock is measured in hours that nobody is counting out loud.
The Restore Arithmetic
Here is the number everyone skips. A 4 TB estate, restored from a copy held somewhere else, over a link of a given speed, at theoretical full line rate — and then the same figure at a realistic 70% of it, which is a generous assumption for a sustained transfer:
| Link | At full line rate | Realistic (≈70%) |
|---|---|---|
| 100 Mbps | 89 hours | about 5 days |
| 200 Mbps | 44 hours | about 2.5 days |
| 500 Mbps | 18 hours | about 25 hours |
| 1 Gbps | 9 hours | about 13 hours |
| 10 Gbps | 53 minutes | about 75 minutes |
Run your own storage figure through it before you read on, because the shape of the answer matters more than ours. Most of the estates we see are on the top three rows.
Why That Table Is the Optimistic Part
Every figure above is the time to copy bytes, and copying bytes is the one step in a recovery that is easy to predict. The steps around it are not in the table:
- Somewhere to put it. If the restore target is the platform that just failed, there is a procurement conversation before there is a transfer. Hardware does not arrive during an incident.
- What the restore did not carry. Network configuration, firewall rules, load balancer members, certificates, licence activations tied to hardware, scheduled tasks, and whatever lived on a machine nobody documented.
- Addressing and DNS. The restored estate is somewhere else, which means different addresses, and records with a TTL that was set years ago by someone who was not thinking about this day.
- Proving it works. Applications come back in an order. Finding out what that order is, while the business watches, is the part that turns a nine-hour transfer into a two-day outage.
None of this is exotic. It is simply work that has to happen in sequence, by people who are also fielding questions, and it is invisible when the plan is a line item that says “we have backups”.
Three Things Backup Alone Does Not Cover
The site going away. If the copy lives in the same building as the original, it is a convenience feature, not a recovery plan. If it lives elsewhere, the table above applies, and the second site has to be somewhere you are allowed to recover into — which in the UAE is a question about jurisdiction as much as geography.
Ransomware going for the backups first. This is now standard practice, not a worst case. An attacker who has been in the estate for three weeks has found the backup server, and the credentials for it were probably on a machine they already own. Backup that can be reached from the production domain is backup that can be encrypted with it.
Time itself. A restore is linear in how much data you have. A business’s tolerance for downtime is not — it is a cliff somewhere, and the cliff does not move because your estate grew.
Where the Line Actually Is
The useful question is not “backup or DR”. It is which workloads, and to what standard. Most estates need both, applied unevenly.
If an outage of a working day would cost real money, lose customers, or breach something you have signed, that workload needs a second environment that is already running — and that is disaster recovery. If the honest answer is “we would be annoyed but fine until Thursday”, that workload needs good backup with a tested restore, and the money saved should go to the first group.
Replicating everything is how a DR budget dies, and it is the most common failure we see after doing nothing at all. The next post in this series is about the two numbers that decide which group a workload belongs in.
What We’d Suggest Doing About It
Before anyone quotes you anything, do the arithmetic for your own estate — it takes a few minutes and it changes the conversation. The DR planner takes nine answers and shows you four numbers: the replica storage your estate implies, how long a first seed takes over your uplink, how much bandwidth continuous replication consumes afterwards, and what your recovery target forces to be running already rather than waiting to be started. No prices, and no email gate on the figures.
If the planner tells you that better backup is the sensible purchase, that is a real answer and we will say so on the call. We would rather do that than sell a replication platform that gets cancelled in a year.
Next in the series: RTO and RPO — the two numbers that decide everything, and what each choice actually forces you to pay for.
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.
