Backup vs disaster recovery, and BC vs DR plans explained
Key takeaways
- A backup is a copy of files and programs made to help recovery; on its own it is not a recovery plan
- A disaster recovery plan covers recovering information systems after a major hardware or software failure or the loss of a facility
- A business continuity plan covers how business processes keep going during and after a significant disruption, including people and manual processes
- AWS advises that the disaster recovery plan should be a subset of the business continuity plan, not a standalone document
- The NCSC says an incident response plan should sit alongside inter-linked business continuity, disaster recovery and communications plans
Backup, disaster recovery (DR) and business continuity (BC) are often used as if they meant the same thing. They do not. A backup is a copy of your data. Disaster recovery is the plan for getting your systems running again after a major failure. Business continuity is the wider plan for keeping the business itself going. This guide explains each one, how they fit together, and what each plan should cover.
What is a backup?
NIST defines a backup as a copy of files and programs made to facilitate recovery if necessary. A backup is something you have. It does not, by itself, tell anyone what to restore first, where to restore it to, or who decides.
Backups also need protecting. AWS notes that continuous replication of data may not protect against data corruption or malicious attack, such as unauthorised data deletion, as well as point-in-time backups do. Our guide to immutable vs air-gapped backups covers keeping copies an attacker cannot reach, and the 3-2-1 backup rule guide covers how many copies to keep and where.
What is disaster recovery?
NIST's glossary gives a disaster recovery plan (DRP) as a written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. Another definition it lists describes the DRP as the plan used when the enterprise must recover at its original facilities from a loss of capability over a period of hours or days.
Microsoft's guidance describes disaster recovery as planning how to deal with uncommon risks and the catastrophic outages that can result. It gives a natural disaster or a major network attack as examples of such uncommon risks. Day-to-day issues such as brief network outages or restarts for patching are common risks that Microsoft says a high availability strategy must handle, while disaster recovery deals with rare risks.
What is business continuity?
NIST defines a business continuity plan (BCP) as the documentation of a predetermined set of instructions or procedures that describe how an organisation's mission or business processes will be sustained during and after a significant disruption.
The BCI quotes the ISO 22301:2019 definition of business continuity: the capability of an organisation to continue the delivery of products and services within acceptable time frames at a predefined capacity during a disruption. ISO 22301 is the international standard for business continuity management systems.
Business continuity is wider than IT. Microsoft says a robust business continuity plan incorporates all aspects of support in the business, including people, business-related manual or automated processes, and other technologies.
Backup vs disaster recovery vs business continuity
| Backup | Disaster recovery | Business continuity | |
|---|---|---|---|
| What it is | A copy of files and programs | A plan for recovering information systems | A plan for sustaining business processes |
| Covers | Data | Systems, infrastructure, configuration and code | People, processes and technology |
| Used when | Data is lost, corrupted or deleted | A major failure or loss of a facility | Any significant disruption |
How they fit together
AWS says your disaster recovery plan should be a subset of your organisation's business continuity plan, not a standalone document. Its example is an earthquake: even if effective disaster recovery keeps an online shop's systems running, the business continuity plan still needs to deal with transporting the products customers bought.
The NCSC makes a similar point about cyber incidents. In addition to an incident response plan, it says you should have inter-linked business continuity, disaster recovery and communications plans, covering internal and external communications.
In our view, one way to keep the three in step is to work top down: the business decides what has to keep going and how quickly, disaster recovery sets how each system gets back in time, and backups make sure there is data to recover.
Disaster recovery strategies, from backup to active/active
AWS groups disaster recovery strategies into four approaches, ranging from the low cost and low complexity of making backups to more complex strategies using multiple active AWS Regions:
- Backup and restore. AWS says this is a suitable approach for mitigating against data loss or corruption.
- Pilot light.
- Warm standby.
- Multi-site active/active.
Backup and restore is the point where backup and disaster recovery meet, and it shows why a backup is not a recovery plan on its own. AWS says that in addition to data, you must redeploy the infrastructure, configuration and application code. Without infrastructure as code it may be complex to restore workloads, which will lead to increased recovery times and possibly exceed your recovery time objective (RTO). It also advises backing up code and configuration, not just user data.
How often you back up determines your achievable recovery point, which should align with your recovery point objective (RPO). Our guide to RPO, RTO and MTD explains how to set those targets.
AWS adds that if the cost of a recovery strategy is higher than the cost of the failure or loss, it should not be put in place unless there is a secondary driver such as regulatory requirements.
What a business continuity plan should contain
Microsoft lists four steps for business continuity planning:
- Criticality tier classification. Classify workloads into tiers based on their importance to the business.
- Risk identification. Identify risks to availability, such as network issues, hardware failures, human error or a region outage, and understand the impact of each.
- Risk classification. Treat common risks in high availability plans and uncommon risks in disaster recovery plans.
- Risk mitigation. Design strategies such as redundancy, replication, failover and backups, and consider nontechnical and process-based controls too.
AWS recommends a business impact analysis that quantifies the impact of a disruption on internal and external customers, and helps determine how quickly a workload needs to be available and how much data loss can be tolerated. It notes that impact can depend on timing: a payroll system outage matters far more just before payday than just after it.
Microsoft says business continuity planning is a process, not a one-time event, and the plan should be reviewed and updated regularly.
What a disaster recovery plan should contain
In our view, a disaster recovery plan should cover at least:
- the systems in scope, in the order they must come back
- the RTO and RPO for each system, taken from the business continuity plan
- where backups are kept, and how to restore from them
- how to rebuild infrastructure, configuration and application code
- who can declare a disaster and who carries out each step
- how and when the plan is tested
For the people part, the NCSC's advice for incident response plans applies here too: consider the risk of people being unavailable, and ideally include at least two contact methods and two or more people or groups.
Test it
AWS says it is critical to regularly assess and test your disaster recovery strategy so that you have confidence in invoking it. Our guide to how often to test disaster recovery and business continuity plans covers how often, and what kind of test to run.
Frequently asked questions
What is the difference between backup and disaster recovery?
A backup is a copy of data, files and programs that makes recovery possible. Disaster recovery is the documented plan and capability for getting information systems running again after a major failure, which also needs infrastructure, configuration and application code, not only data.
What is the difference between a business continuity plan and a disaster recovery plan?
A business continuity plan describes how the organisation's business processes will be sustained during and after a significant disruption. A disaster recovery plan is narrower: it covers recovering information systems after a major hardware or software failure or the loss of a facility.
Is a backup enough for disaster recovery?
Not on its own. AWS describes backup and restore as the lowest cost and least complex disaster recovery strategy, but it still means redeploying the infrastructure, configuration and application code, and without infrastructure as code that can take long enough to miss your recovery time objective.
Should the disaster recovery plan be part of the business continuity plan?
AWS advises that it should be a subset of the business continuity plan rather than a standalone document, because keeping a system running does not help if the rest of the business cannot operate.
What is ISO 22301?
ISO 22301 is the international standard for business continuity management systems. The BCI describes it as a framework to plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system for disruptive incidents.
