Skip to content
Knowledge Hub/Article
Article

What Is Disaster Recovery? How to Build a DR Plan

Disaster recovery brings IT systems and data back after a disaster. How it differs from backup, recovery site types, DRaaS and what goes in a DR plan.

Oğuzhan Gerçek··8 min read
What Is Disaster Recovery? How to Build a DR Plan

Short answer: Disaster recovery (DR) is the ability to bring IT systems and data back after an event such as a fire, an earthquake, a major hardware failure, a cyberattack or human error. Its success is measured against two targets: how soon a system must be running again (RTO) and how much data you can afford to lose (RPO). Backup is one part of disaster recovery; high availability does not replace it, because it carries deleted or corrupted data over to the second copy as well. A good DR plan sets out roles, how a disaster is declared and the failover and failback steps, and it is proven through regular testing.

What is disaster recovery?

In Google Cloud's definition, disaster recovery is an organization's ability to restore access to and functionality of its IT infrastructure after a disaster, whether natural or caused by human action or error. AWS gives earthquakes and fires, technology failures, human error and unauthorized access by third parties as examples of disasters.

The contingency planning guide from the US National Institute of Standards and Technology (NIST), SP 800-34 Rev. 1, defines a disaster recovery plan (DRP) as a written plan for recovering information systems at an alternate facility after a major hardware or software failure or the destruction of facilities. You will find a short definition in our glossary.

How it differs from backup, high availability and business continuity

These four ideas are often confused:

  • Backup: According to Google Cloud, backup is a component of disaster recovery. Backup focuses on copying data and getting it back; disaster recovery is the broader strategy for restoring IT systems and business operations. We cover backup types in our backup article.
  • High availability (HA): According to AWS, availability focuses on the components of a workload, while disaster recovery focuses on discrete copies of the entire workload. In storage that replicates continuously, a deleted or corrupted file is mirrored to the second copy too, so a DR strategy also needs point-in-time backups. Measuring availability is the subject of our uptime article.
  • Business continuity: Google Cloud treats disaster recovery as the subset of business continuity that focuses on IT systems, and AWS says a DR plan should be part of the business continuity plan. We cover the wider framework, which also takes in people, processes and suppliers, in our business continuity article.

RPO and RTO: the two targets of disaster recovery

As AWS defines them:

  • RTO (recovery time objective): The maximum acceptable delay between the interruption of service and its restoration.
  • RPO (recovery point objective): The maximum acceptable amount of time since the last data recovery point; in other words, the data loss you accept.

Google Cloud's planning guide points out the cost side: the smaller your RTO and RPO, the more the application typically costs to run. That is why targets are set system by system; we show how to derive them from business cost in how to calculate RPO and RTO.

Hot, warm and cold sites

The second location where recovery takes place is called a disaster recovery site. NIST SP 800-34 classifies these sites by how ready they are:

  • Cold site: Has power, telecommunications and environmental controls but no computer equipment; the equipment is brought in after the disaster.
  • Warm site: Has some or all of the system hardware, software and telecommunications in place.
  • Hot site: Stands by fully operational, with hardware and software.
  • Mirrored site: Fully redundant, with automated real-time mirroring of data.

Google Cloud explains the difference with a tire analogy: in the cold pattern you have no spare and must wait for someone to bring a new tire, in the warm pattern you have a spare and a kit, and in the hot pattern you drive on with run-flat tires.

In the cloud, the same tiers map to four strategies in AWS's classification:

  • Backup and restore: The cheapest and simplest approach; the system is rebuilt from backups after the disaster.
  • Pilot light: Data is replicated continuously and the core infrastructure is in place, but application servers are switched on only when disaster strikes.
  • Warm standby: The workload already runs at reduced capacity in a second Region and can take traffic immediately.
  • Multi-site active/active: Traffic is served from every Region, and recovery time approaches zero for most disasters; it is also the most complex and expensive option.

DRaaS: disaster recovery as a service

According to Google Cloud, with DRaaS your data and IT infrastructure are backed up and hosted on a third-party provider's cloud, and the provider implements the DR plan during a crisis. Cloud platforms' own recovery services work in a similar way: Azure Site Recovery replicates workloads from a primary site to a secondary location; during an outage you fail over to it, and you fail back once the primary location is running again.

DRaaS moves the burden of running a second site to the provider, but not ownership of the plan: Microsoft wants the DR plan to define the responsibilities between your team and the provider. We discuss the choice between building your own recovery site and using DRaaS in our enterprise disaster recovery strategy article, and how the setup is run on our disaster recovery engineering page. There is a short definition of the term in our glossary.

What goes into a disaster recovery plan?

NIST SP 800-34 divides the plan into three phases: activation and notification, where the plan is activated and recovery staff are notified; recovery, where the system is run at an alternate site or with contingency capabilities; and reconstitution, where the system is tested and returned to normal operation. Microsoft's Well-Architected guidance says the plan should set out at least the following:

  • Who declares a disaster, closes the incident and runs testing and validation, plus the escalation paths
  • Criteria that tell a full disaster apart from a major disruption and from a small issue that can be fixed quickly
  • Step-by-step failover instructions with their prerequisites (scripts, credentials, configurations)
  • Post-failover tasks: DNS updates, traffic routing, connection string changes
  • Failback as a separate process, which according to Microsoft may happen immediately or over days or weeks

Google Cloud adds that each task should consist of concrete, unambiguous commands or actions; an instruction such as "run the restore script" is too general.

Disaster recovery testing

According to NIST, tests validate the plan's components with quantifiable metrics. The guide's example test areas are notification procedures, system recovery on an alternate platform from backup media, internal and external connectivity, and restoration of normal operations. AWS recommends testing the plan at least once or twice a year, and Microsoft recommends reviewing it ideally every six months. Microsoft wants the plan to cover tabletop exercises, dry runs outside production and production-level drills; only production drills show whether RTO and RPO targets hold up in real conditions.

We explain how to set up a test step by step, and why failback needs its own rehearsal, in our disaster recovery testing article.

The ransomware scenario

With ransomware, the problem is not the loss of a facility or hardware but encrypted data. That is why a design that relies on replication alone falls short: as AWS warns, corrupted data is mirrored to the second copy too. CISA's #StopRansomware Guide recommends the following for preparation and recovery:

  • Keep offline, encrypted backups of critical data, and regularly test their availability and integrity in a disaster recovery scenario
  • Rebuild systems based on the priority of critical services, and restore data from offline backups in the same order
  • Identify dropper malware before rebuilding from backups, and avoid reinfecting clean systems

We explain how to choose the right recovery point with immutable backups and a journal in our ransomware recovery playbook. We handle running backups in our backup, replication and recovery service and keeping data protected in our data protection and recovery service.

Frequently asked questions

What does disaster recovery mean? Bringing IT systems and data back after a disaster. It is usually shortened to DR.

What is a DR plan? A written plan describing how information systems will be brought back after a major failure or the loss of a facility. It covers roles, declaring a disaster, and the failover and failback steps.

What is the difference between disaster recovery and backup? Backup keeps a copy of the data and is one part of disaster recovery. Disaster recovery also covers getting systems, the network and applications running again.

Are disaster recovery and business continuity the same thing? No. Disaster recovery focuses on IT systems; business continuity also covers people, processes and suppliers. The DR plan is part of the business continuity plan.

What is DRaaS? Disaster recovery as a service. Your data and infrastructure are backed up on a provider's cloud, and the provider runs the recovery during a crisis.

Sources