Comparison
Backup, disaster recovery and business continuity are not the same thing
Backup is a copy of your data. Disaster recovery is how quickly you are working again. Business continuity is how the business keeps trading meanwhile. Most firms buy the first and assume the other two.
By Claire Donnelly · Last reviewed 11 August 2026 · 4 min read
The short version
- Backup answers whether you can get the data back at all
- Disaster recovery answers how quickly the systems are running again
- Business continuity covers people, premises and phones, not only IT
- RTO is how long you can afford to be down; RPO is how much data you can lose
- Most businesses have bought backup and quietly assume they have all three
Three different questions
The three terms get used as though they were grander and grander words for the same purchase. They are not. Each answers a different question, and you can have a confident answer to one while having none at all to the others.
Backup asks: if this data disappeared, could we get it back?
Disaster recovery asks: when something significant breaks, how long until people are working again, and how much recent work do we lose?
Business continuity asks: while that is going on, how does the business keep serving customers?
A company can have immaculate backups, no disaster recovery plan, and no idea what staff would do for the two days it takes to rebuild a server. That is a very common position, and it usually goes unnoticed because the backup reports are green.
The question it answers
Backup
Can we get the data back?
Disaster recovery
How soon can we work again?
What it produces
Backup
A copy of files, mail or systems
Disaster recovery
A tested route back to running
Measured by
Backup
How far back you can reach
Disaster recovery
How long the recovery takes
If a server dies
Backup
The data survives; rebuilding takes days
Disaster recovery
Systems return within an agreed time
Typical cost
Backup
Modest, and predictable
Disaster recovery
Higher - it needs standby capacity
What it will not do
Backup
Get you working again quickly
Disaster recovery
Rescue you from a bad copy
| Backup | Disaster recovery | |
|---|---|---|
| The question it answers | Can we get the data back? | How soon can we work again? |
| What it produces | A copy of files, mail or systems | A tested route back to running |
| Measured by | How far back you can reach | How long the recovery takes |
| If a server dies | The data survives; rebuilding takes days | Systems return within an agreed time |
| Typical cost | Modest, and predictable | Higher - it needs standby capacity |
| What it will not do | Get you working again quickly | Rescue you from a bad copy |
Which should you choose?
Backup is necessary and not sufficient. It protects the data and says nothing about how long you sit idle while somebody rebuilds. If a week offline would be survivable, backup alone may genuinely be enough - that is a legitimate decision. If it would not, recovery has to be planned and tested, and it is bought differently.
The two numbers that decide what you need
Recovery planning turns on two figures, and they are worth agreeing before anybody quotes you for anything.
Recovery time objective is how long the business can be without a system before the damage becomes serious. Not how long you would like – how long you can actually stand.
Recovery point objective is how much recent work you can afford to lose. A nightly backup means a bad morning could cost you a day’s work; if that is unacceptable, you need copies taken more often.
Those two numbers, honestly answered, do most of the work. They tell you whether nightly backup is fine, whether you need replication, and how much it is reasonable to spend. Without them, every quote looks arbitrary, because it is.
Business continuity is the part nobody owns
Continuity is the widest of the three and the one least likely to have anybody’s name against it, because most of it is not an IT problem at all.
If the office is flooded, where do people sit? If the phones are down, how do customers reach you, and who tells them? If the person who knows how payroll runs is unavailable for a fortnight, who does it? If your main supplier’s systems fail, what happens to your orders?
None of that is fixed by a backup. Some of it is fixed by a list of phone numbers and a decision made in advance. Business continuity has grown into a discipline with its own international standard, but a small business does not need a formal programme to benefit – it needs to have thought about the three or four things that would actually stop it trading, and written down what happens.
Questions that expose the gap
- How long could we operate with no access to our main system?
- How much recent work could we afford to lose - an hour, a day?
- When did somebody last restore something and confirm it opened?
- If the office were unusable tomorrow, where would people work?
- Who tells customers what is happening, and how do they reach us?
- Which of these do we have written down, rather than in one person's head?
Common questions
Is cloud storage the same as backup?
No. A sync service copies your current files, including the mistakes - delete something and it removes it from both places. A backup keeps separate historical copies you can return to. Syncing is convenience; backup is recovery.
Do we need disaster recovery if everything is in the cloud?
The shape changes rather than disappearing. Cloud platforms rarely lose your data, but you can still lose access to it through an account compromise, a mistaken deletion or a supplier outage. The question of how long you can be locked out applies exactly the same.
How often should we test a restore?
At least once a year for most small businesses, and more often if the data changes fast or the systems change. Test a real restore of something meaningful rather than confirming the job reported success.
Is a business continuity plan overkill for a small firm?
A formal plan may well be. Half a page listing what would stop you trading, who does what, and how customers are told is not overkill - it is an hour of work that pays for itself the first time anything goes wrong.
Where does ransomware sit across these three?
Across all of them, which is why it is such a useful test. You need copies it cannot reach, a tested way to rebuild quickly, and a plan for operating while that happens. A business with only backup usually survives it, slowly and expensively.
Written by Claire Donnelly
When did anyone last restore one of your backups?
If the answer is "when we set it up" or nobody is sure, that is worth resolving. We'll test a real restore and tell you what came back, how long it took, and what would not have.
Ask for a restore test