Disaster Recovery Planning: RTO, RPO, Backups and How to Build a DR Plan

What is disaster recovery planning?

Disaster recovery planning means deciding how fast each key system must come back after a major outage. You also decide how much data you can afford to lose. Then you build and test the backups, systems and steps to meet those targets. The result is a disaster recovery plan. It is a written, tested set of steps for restoring IT systems after ransomware, a cloud region failure, a deleted database or a fire. Ransomware is malware that locks your files and demands payment.

Disaster recovery (DR) is about getting technology back. It sits alongside two related plans, business continuity and incident response, which we compare below.

RTO and RPO: the two numbers that drive your DR plan

Recovery Time Objective (RTO) is the longest a system can be down before the harm to the business becomes unacceptable. Recovery Point Objective (RPO) is the most data you can accept losing, measured as time. An RPO of one hour means you can lose at most the last hour of changes. So you need backups or replication (live copying) at least every hour.

The lower the numbers, the higher the cost. Set them per system, based on business impact, not one figure for the whole company. The examples below are illustrations, not advice for your business.

A business impact analysis (BIA) is the usual way to set these targets. Ask each system owner what happens to the business after one hour, one day and one week of downtime. Also ask what losing a day of data would mean.

Disaster recovery vs business continuity vs incident response

These three plans are often confused. They overlap, and each should point to the others.

In a ransomware attack, all three run together. The incident response plan contains the attacker. The DR plan restores clean systems. The business continuity plan keeps customers served in the meantime, perhaps with manual workarounds. Useful guides include NIST SP 800-34 for IT contingency planning and ISO 22301 for business continuity management.

The 3-2-1 backup rule and ransomware

The 3-2-1 backup rule is the simplest widely used rule for backups. Keep 3 copies of your data, on 2 different types of storage, with 1 copy offsite.

Ransomware changed the threat. Attackers who gain admin access now often hunt for backup consoles. They delete or encrypt the backups before they launch the ransomware. So if the same admin login can reach both your live systems and your backups, those backups are not safe. Many teams now follow an extended version, often called 3-2-1-1-0:

• 1 immutable or offline copy. Immutable means nobody can change or delete it during its retention period, not even an administrator. Examples include object storage with object lock in compliance mode, immutable backup vaults, or tape kept offline.
• 0 errors when you test restores, because a backup you have never restored is only a hope.

How to build a disaster recovery plan in 7 steps

Follow these seven steps in order. Each one builds on the last.

1. Inventory systems and dependencies. List apps, databases, cloud accounts and SaaS tools. Include DNS, which points your domain names to servers, and identity providers, which handle staff logins. Note how they depend on each other. Recovery most often fails on a forgotten dependency, such as DNS, certificates or the identity provider.
2. Run a business impact analysis. Set RTO and RPO for each system with its business owner.
3. Choose recovery strategies. Match each system to a backup or replication method that meets its targets on budget.
4. Protect the backups. Apply 3-2-1 and add an immutable or offline copy. Encrypt backups and limit who can delete them.
5. Write the runbooks. Write step-by-step restore instructions for each system. A capable engineer who did not build the system should be able to follow them. Include the recovery order.
6. Define roles and communication. Decide who declares a disaster and who leads recovery. Plan how you reach staff if email is down, and how you update customers.
7. Test, then maintain. Schedule tests (below), and review the plan when systems, vendors or people change.

Cloud disaster recovery options

Moving to the cloud does not remove the need for a DR plan. Cloud providers use a shared responsibility model. The provider keeps its own systems running. But protecting your data, settings and accounts from deletion or ransomware is usually your job. The same applies to SaaS (software you rent online). Check what your provider actually backs up and for how long. Do not assume that retention settings or a recycle bin are a backup.

Cloud DR strategies are often described in four tiers. Each one trades cost against recovery speed:

Infrastructure as code (Terraform, CloudFormation and similar) makes cloud recovery much faster. You can rebuild your setup from code stored in a repository instead of from memory. Store that code, and the secrets needed to deploy it, somewhere that survives the loss of your main account.

Testing your disaster recovery plan

An untested DR plan is a guess. Use a mix of tests through the year:

• Restore tests: often restore single files, databases and whole servers from backup. Confirm the data is complete and usable.
• Tabletop walkthroughs: talk through a scenario with the runbooks in hand. For example: "our main cloud account is compromised and locked".
• Partial failover: recover one key system in the DR environment. Measure the actual recovery time against its RTO.
• Full failover: for systems with tight RTOs, rehearse a full switch to the recovery site, where the business can tolerate it.

After each test, record the actual recovery time and data loss. Fix what broke and update the runbooks. SOC 2 and ISO 27001 are security standards that business customers often ask for. Their auditors commonly ask for proof of backup and recovery testing. For SOC 2, this applies when the Availability criteria are in scope.

How NextGarrison helps

NextGarrison helps teams review backup and recovery designs against ransomware, and runs DR tabletop exercises. We also link disaster recovery to incident response, so restoring systems does not also restore the attacker. Our 24/7 SOC and incident response services support you during the event itself. A SOC is a team that watches your systems for attacks around the clock. See our security services. Or read our guide to SOC 2 compliance if DR testing is part of your audit preparation.