Backup and disaster recovery are not the same purchase
"We have backups" and "we can be running again by tomorrow morning" are different claims, and the gap between them is where businesses get hurt. A backup is a copy of your data. Disaster recovery is the ability to turn those copies back into a working business — servers booting, staff signing in, invoices going out — within a timeframe you decided in advance rather than discovered on the day.
The distinction matters because the failure modes are different. Backups fail quietly: a job that has been erroring for months, an agent that was never installed on the new server, a repository that filled up and stopped. Recovery fails loudly: the data is all there, but nobody knows the restore order, the credentials live in the head of someone on leave, and what should have been a Tuesday-morning inconvenience becomes a week of downtime.
Untested backups fail when you need them most, and most businesses discover this on the worst possible day. Our position is simple: a backup that has not been restored is a hope, not a control. That is why the restore test — not the backup job — is the deliverable we sell.
What 3-2-1 means, and why the offsite copy must be immutable
The 3-2-1 rule is the industry's shorthand for a sane backup architecture: three copies of your data, on two different types of media, with one copy offsite. The original on your live server counts as the first copy; an onsite backup repository gives you the second and makes routine restores fast; the offsite copy protects you when the problem is the site itself — fire, theft, flood, or ransomware that reached everything on the network.
Ransomware changed one part of this. Modern attacks go looking for backups before encrypting anything, precisely because a working backup is what lets a victim refuse to pay. If your offsite copy is just another network share, it gets encrypted along with everything else. The answer is immutability: an offsite copy written so that it cannot be altered or deleted for a defined period — not by an attacker, not by a compromised administrator account, not by us.
In our deployments that means Veeam Backup & Replication with an onsite repository for fast day-to-day restores and an immutable cloud tier for the offsite copy. We are a Veeam Silver VAR, so the team that sells the licence is the team that configures and supports it.
RPO and RTO in plain language
Two numbers define every backup design, and both are business decisions dressed up as technical ones. RPO — recovery point objective — is how much work you can afford to lose, measured in time: if the server dies at 4pm and the last good backup ran at midnight, sixteen hours of work is gone. RTO — recovery time objective — is how long you can afford to be down while the restore runs.
Neither number should be uniform across the business. The accounting system and the live file server do not carry the same tolerance for loss as an archive of old projects, and paying for a tight RPO on everything means overpaying on most of it. So we set RPO and RTO per workload, write them into the DR runbook, and design the backup schedule and infrastructure to meet them — rather than buying a product and hoping the numbers fall out.
The honest part: an RTO is only real once it has been measured. A restore test that stands a workload up in a clean environment tells you what your actual recovery time is. If it does not meet the objective, you want to learn that during a drill, not during an outage.
Microsoft 365: retention is not a backup
The most common gap we find in otherwise well-backed-up businesses is the Microsoft 365 tenant. The assumption is understandable — it is Microsoft's cloud, surely they back it up — but what Microsoft provides is availability and retention: recycle bins, version history, retention policies and legal hold, all with time limits, and all operating inside the same tenant.
None of that reliably protects you from the scenarios that actually cause data loss: a mailbox emptied by a compromised account, ransomware encrypting files that then sync through OneDrive, a leaver's account deleted before anyone thought about the data in it, or a SharePoint library purged past its retention window. Retention answers "keep this for so many years"; a backup answers "put it back the way it was on Tuesday". They are different tools.
Veeam Backup for Microsoft 365 closes the gap — mailboxes, OneDrive, SharePoint and Teams, backed up outside the tenant on a schedule you control, restorable down to a single item. If your business runs on Microsoft 365, this is not an optional extra; it is where most of your data now lives.
Our Microsoft 365 service in full →
What a DR drill actually involves
Every quarter we restore a sample workload into a clean environment and verify it boots — not "the report says the job succeeded", but an actual machine, started from backup, checked. The drill produces three things: proof the backups restore, a measured recovery time to hold against your RTO, and a list of everything that was harder than it should have been.
- The runbook — who declares the disaster, who runs what, in what order, with what credentials — written down so the recovery does not depend on one person's memory or availability at 2am. Reviewed annually.
- The restore order — systems depend on each other; the domain controller, the file server and the accounting package cannot all be first. The order is decided in advance, while nobody is under pressure.
- The timings — each drill's restore times recorded, so the answer to "how long would we be down" is a measurement rather than an estimate.
- The evidence — for regulated clients, the drill record itself is a deliverable — what was restored, when, how long it took — ready to hand to an auditor.
Between drills, backup jobs are monitored, because the most common backup failure is not dramatic — it is a job that quietly stopped and nobody noticed for months.
See how backup ownership fits into an AMC →