A backup is a copy of your data. Disaster recovery is the plan to get your business running again. They're related, but they're not the same thing — and the gap between them is where businesses get caught out.
A backup answers one question: if a file or a server disappears, do we have a copy? Disaster recovery answers a bigger one: if a whole system goes down — ransomware, hardware failure, a cloud region outage — how long until the business is actually running again, and in what state? Having backups is necessary for disaster recovery. It isn't the same as having a tested plan for using them under pressure.
Business continuity is the layer above both: not just "can we get the servers back," but "can the business keep operating" — including things a technical restore doesn't cover, like how staff communicate, which processes run manually in the meantime, and who's actually authorised to make decisions during an outage.
| Term | The question it answers | Who should decide it |
|---|---|---|
| RTO Recovery Time Objective | How long can we tolerate a system being down? | The business, based on real operational impact |
| RPO Recovery Point Objective | How much data can we afford to lose, in time? | The business, based on acceptable risk |
These aren't IT decisions to make in isolation — they're business decisions about acceptable risk, and the technical plan should be built to meet targets the business has actually agreed to, not whatever a backup tool defaults to.
Backups exist. Restores get tested rarely, if ever. The gap between "we have backups" and "we know our restore works, and how long it takes" is exactly where businesses get an unpleasant surprise — discovering during an actual incident that a backup was incomplete, corrupted, or simply much slower to restore than anyone assumed.
For workloads already running on Azure, or being considered for it, Azure Site Recovery is Microsoft's own orchestration tool for replicating virtual machines to a secondary region and failing over when something goes wrong. It's a strong building block — but it still needs to sit inside a broader plan that covers the non-technical side: communication, decision-making, and what "back to normal" actually means for your business.
A workable plan has four things in place. If any of them isn't true today, that's the practical starting point — more useful than researching new backup tools.
At least annually for most SMEs, and after any significant change to critical systems. A plan that's never been tested is unverified, not proven.
It depends entirely on how much data loss the business can tolerate — for many SMEs a few hours is reasonable, for transaction-heavy systems it may need to be much shorter. This should be a deliberate decision, not a default setting.
Backup is necessary but not sufficient. Without a documented, tested plan for using it — who acts, in what order, how the business communicates — a backup answers “do we have the data,” not “how fast are we back running.”
Book a free backup and disaster recovery assessment — we'll help you find out before you need to.
