Disaster Recovery and Backup for Cloud-First and Remote Businesses
A backup is a claim. A restore is a fact.
A backup is a claim. A restore is a fact. Most disaster recovery arrangements we assess have never been tested end to end, which means the business is holding a claim and calling it a fact.
This is not usually negligence. Backup software reports success, the dashboard is green, and there is no obvious reason to doubt it. The gap only appears when someone tries to restore something substantial under time pressure, which is exactly the worst moment to discover it.
Recovery objectives are a business decision
Two numbers drive every disaster recovery design, and neither of them is technical:
- Recovery time objective (RTO) — how long the business can be without the system before the consequences become serious.
- Recovery point objective (RPO) — how much recent work the business can afford to lose and re-do.
These get set by the people who carry the consequences, not by whoever configures the software. A practice that cannot see patients without its records has a different RTO to a firm whose worst case is a slow week. The technical design follows from the answer; when it is skipped, the design defaults to whatever the product does out of the box, which is nobody’s deliberate choice.
They should also be set per system rather than for everything at once. A single disaster recovery tier applied across the whole estate always overspends somewhere: paying for four-hour recovery on a file archive nobody has opened in two years is a real and common waste.
What a credible disaster recovery design contains
Copies that survive the thing that destroyed the original. The old three-two-one guidance still holds: three copies, two different media or platforms, one off-site. Modern ransomware makes the off-site copy insufficient on its own, because an attacker with domain credentials will go looking for the backup system first.
At least one immutable copy. Written once, not deletable or modifiable for a defined retention window, and not reachable with the same credentials that administer the production estate. This is now the control that decides ransomware outcomes more than any other.
Microsoft 365 included. Microsoft operates the service and protects the platform; it does not undertake to restore your data after an accidental deletion, a retention policy misconfiguration, or a compromised account deleting mail deliberately. The shared responsibility model is explicit about this — it is set out plainly in Microsoft’s shared responsibility documentation. Assuming otherwise is one of the most common gaps we find.
A written runbook. Restore steps, in order, with the credentials location noted — readable by someone who is not the person who built it, and stored somewhere reachable when the primary systems are down. A recovery plan that only exists on the file server is not a recovery plan.
The drill is the deliverable
The part that separates a real arrangement from a hopeful one is a restore actually performed, on a schedule, with the results written down.
A drill establishes things a dashboard cannot: how long a full restore genuinely takes on your connection, whether the runbook is followable by the person who will be holding it at 03:00, whether the restored system actually starts and talks to everything it needs to, and whether anyone has the credentials required.
Application-consistent restore is the failure that surprises people most. A database backed up while running, without the correct quiescing, restores to a state the application will not open. The backup completed. The file is there. It is useless. This is only ever discovered by trying.
We have written up the seven failures a restore drill reliably exposes in our piece on backup testing and what a drill actually finds. The public reference for building the plan around it is NIST SP 800-34, the contingency planning guide — freely available and rather more useful than most vendor material.
How this connects to everything else
Disaster recovery is the control that sits underneath the others. Identity hardening, endpoint detection and email security all reduce the likelihood of an incident; recovery determines what an incident costs when one gets through anyway. Treating it as a security control rather than as IT housekeeping is the correct framing, and it is how insurers treat it — tested backups appear on effectively every cyber insurance application, as we set out in the controls underwriters check.
It also carries a compliance edge in South Africa. POPIA requires that personal information be protected against accidental loss or destruction, not only against unauthorised access — so a business that cannot restore has a compliance problem as well as an operational one. The technical detail is in our POPIA compliance checklist.
What an engagement looks like
A disaster recovery engagement runs in four steps, and the first two are the ones that get skipped:
- Establish what matters. Which systems, which data, and the RTO and RPO for each, agreed with the business rather than assumed.
- Assess what exists. What is actually being backed up, where the copies live, who can delete them, and how far back the retention really goes as opposed to how far back it is configured to go.
- Close the gaps. Usually immutability, Microsoft 365 coverage, and separating backup credentials from production administration. Often less expensive than expected, because the licensing is frequently already owned.
- Drill it, then put the next drill in the calendar. With a written result, including how long it took. That document is what you show an insurer, a client or an auditor.
Connectivity is a design constraint, wherever you are
This work is designed and tested remotely for clients anywhere, and on site across the Helderberg and Cape Town. The one thing that is never remote is the data itself, and it is worth being unsentimental about that: restoring several terabytes over a typical business line takes considerably longer than most recovery plans assume, which is usually the argument for keeping a local copy alongside the cloud one. That calculation is specific to your connection, not to ours, so it gets done against your real link speed rather than a brochure figure.
If you want to know where you stand before committing to anything, the useful first step is small: pick your most important system and ask when it was last restored from backup in full. If the answer is "never" or "not sure", that is the finding, and everything else follows from it.