Backup & Continuity
Backup vs disaster recovery: what's the difference, and why you need both
Backups copy your data. Disaster recovery gets your business running again. Learn the difference, what RPO and RTO mean, and the Microsoft 365 backup gap.
By Dig IT SolutionsUpdated 8 September 20267 min read
Short answer
A backup is a copy of your data that you can restore if the original is lost or encrypted. Disaster recovery is the tested plan, systems and people that get your business operating again after a serious incident. Backups protect information. Disaster recovery protects operations. Most UK SMEs need both, with defined recovery time and recovery point objectives.
Ask most business owners whether they are covered for a serious IT incident and the answer is "yes, we have backups". That answer is half right. Backups solve one problem: getting your data back. They do nothing about the other problem: getting your servers, applications, phones and staff working again while you wait. This article explains the difference between backup and disaster recovery, the two numbers (RPO and RTO) that should drive every decision, and the gaps that catch UK SMEs out most often.
What a backup actually is
A backup is a copy of your data, stored separately from the original, that you can restore when the original is lost, corrupted, deleted or encrypted. That covers everyday problems: a deleted client folder, a failed laptop drive, a corrupted database after a bad update, or a ransomware infection that has been contained.
Backups come in several forms:
- Full backups copy everything. Simple to restore from, slow to run, heavy on storage.
- Incremental backups copy only what changed since the last backup. Fast and light, but a restore has to chain several sets together.
- Differential backups copy everything changed since the last full backup. A middle ground.
- Image backups capture a whole server or PC, including the operating system and applications, so it can be rebuilt as a unit rather than file by file.
Where the copy lives matters as much as how it is taken. On-site backups (a Synology NAS, a backup appliance) restore quickly over the local network. Cloud backups survive fire, flood and theft but restore more slowly over the internet. Most of the businesses we support run both, and our guide to on-site, cloud and hybrid backup goes into the trade-offs.
The 3-2-1 rule is the standard yardstick: three copies, on two types of media, one of them off-site. The National Cyber Security Centre's small business guide adds a fourth requirement that has become essential in the ransomware era: at least one copy must be offline or immutable, so an attacker who gets into your network cannot delete the backups before encrypting the live data.
What disaster recovery actually is
Disaster recovery (DR) is the set of arrangements that gets your business operating again after an incident that takes out systems, not just files. It answers questions a backup cannot:
- Which systems come back first, and in what order?
- Where do we restore to if the server room is under water or the hardware is dead?
- Who has the credentials, the licence keys and the supplier contacts?
- How do staff work, take calls and serve customers during the rebuild?
- How long will all of this take, and has anyone proved it?
A DR plan typically includes an inventory of critical systems with their dependencies, defined recovery objectives for each, documented step-by-step procedures, alternative ways of working, a communication plan, and a testing schedule. Larger organisations add replication (a standby copy of servers kept in sync in the cloud) and automatic failover. For a 20-person firm, DR may be as simple as a tested image backup, a cloud location it can be restored into, and a one-page runbook that a second person can follow.
The point is that DR is about time and operations. Backup is about data.
Backup vs disaster recovery: side by side
| Backup | Disaster recovery | |
|---|---|---|
| Purpose | Get data back | Get the business running |
| Scope | Files, databases, mailboxes, images | Servers, applications, networks, phones, people, process |
| Key measure | Recovery point objective (RPO) | Recovery time objective (RTO) |
| Handles | Deletion, corruption, single device failure, contained malware | Site loss, hardware failure, full ransomware outbreak, prolonged outage |
| Typical tools | Backup software, NAS, cloud backup, Microsoft 365 backup | Image-based restore, cloud failover, runbooks, spare hardware, tested procedures |
| Owner | IT | Business leadership, supported by IT |
| Proof it works | Successful test restore | Successful full recovery exercise against the clock |
RPO and RTO: the two numbers that matter
Every decision about backup and DR should start with two figures, agreed by the business rather than guessed by IT.
Recovery point objective (RPO) is the maximum amount of data, measured in time, you are prepared to lose. If your RPO for the accounts system is one hour, backups of that system must run at least hourly. A nightly backup gives you a 24-hour RPO whether you like it or not.
Recovery time objective (RTO) is the maximum time you can be without a system before the harm becomes unacceptable. An RTO of four hours for email and phones, and 24 hours for the archive server, tells everyone what to fix first and what standby capacity you need.
Backups largely set your RPO. Disaster recovery arrangements set your RTO. A business can have a superb RPO (backups every 15 minutes) and a dreadful RTO (three days to source and rebuild a server) at the same time, which is exactly the trap of "we have backups, so we are fine". We work through a costed example in RTO vs RPO explained.
In practice, the businesses we support that take this seriously back up frequently and keep a fast local copy. Mr Plant Hire, a multi-depot plant and tool hire business, has its servers backed up locally several times a day and to the cloud. If a server fails mid-afternoon, the local copy restores quickly and only the last couple of hours of work are at risk.
Why one without the other leaves you exposed
Backups without DR. A firm of solicitors backs up every case file nightly to the cloud. A ransomware attack encrypts every server on a Friday evening. The files are safe, but nobody has documented how to rebuild the domain controller, the practice management server or the phone system, and the only person who knows the passwords is on leave. The data is recoverable. The firm is still closed on Tuesday.
DR without good backups. A distribution business replicates its servers to a standby environment so it can fail over in minutes. Malware sits undetected for three weeks before it triggers. By then the replica carries the same infection and the only clean backups have been overwritten by the retention policy. Fast failover, nothing clean to fail over to.
Both together. The same distribution business keeps 90 days of versioned, immutable backups alongside its replication. When the malware triggers, it fails over for immediate operation, identifies the last clean restore point, and rebuilds from that. Lost data: a few hours. Lost trading: an afternoon.
The Microsoft 365 gap
A large share of SMEs now keep their most important data in Microsoft 365: email, Teams chat, SharePoint and OneDrive. Many assume Microsoft backs all of this up. Microsoft keeps the service available and resilient, which is a different thing. Deleted mailboxes, emptied recycle bins and overwritten files age out of Microsoft's retention windows, and ransomware on one laptop will happily sync encrypted files into SharePoint for everyone. Microsoft's own terms of service recommend that customers back up their content, and the platform documentation at Microsoft Learn sets out what retention does and does not cover.
A dedicated Microsoft 365 backup with independent retention is the fix. It costs a few pounds per user per month and turns "I hope Microsoft still has it" into "we can restore that mailbox to any point in the last year".
Building a strategy that covers both
A workable approach for a up to 250 users-person business, and the one behind our backup and disaster recovery service, looks like this:
- List what matters. Identify the systems the business cannot trade without: email, phones, accounts, job or case management, shared files, any line-of-business application.
- Set RPO and RTO for each. Have the directors agree them. Different systems will get different numbers.
- Design backups to meet the RPO. Frequency, retention, local plus cloud, immutable copy, Microsoft 365 included.
- Design recovery to meet the RTO. Image-based backups, somewhere to restore to, spare or cloud capacity, documented runbooks, and a second person who can execute them.
- Plan how staff work in the meantime. VoIP that follows people to their mobiles, cloud email that survives a server loss, manual workarounds for a few hours.
- Test against the clock. Restore a file monthly, a server quarterly, and run a full exercise at least annually. Record how long each takes and compare it with the RTO.
- Review after every change. New systems, new staff, new suppliers and new premises all move the numbers.
Ransomware makes this urgent rather than theoretical. The Cyber Security Breaches Survey 2025 found that around four in ten UK businesses identified a cyber attack or breach in the previous 12 months. Attackers routinely target backups first, which is why immutability and testing are no longer optional extras.
Data protection law adds a further reason. UK GDPR requires organisations to be able to restore access to personal data in a timely manner after an incident, and the ICO's guidance for organisations treats backup and recovery as part of security. A business that loses client records permanently has a compliance problem as well as an operational one.
What to do next
If you can name your backups but not your recovery time, that is the gap to close first. Dig IT designs and runs local plus cloud backup with tested recovery for businesses across Hertfordshire, west Essex and London, and every engagement starts with a review of what you have today. Book an IT health check and we will tell you honestly how long a full recovery would take right now.

