Disaster recovery is not another document for the binder. It is a set of decisions and procedures that, on the day of a serious failure, decide whether the company gets back to work in a few hours or a few weeks. In my audit practice I see the same pattern here: the company has a backup, but no one knows in what order to restore systems or who is responsible for what.

How a DR plan differs from a backup

A backup is a copy of data. Disaster recovery is a plan to restore the company’s operation as a whole: servers, applications, network, access and people. A copy without a recovery plan is like a fire extinguisher without instructions during a fire.

A good DR plan covers:

  • a list of critical processes and the systems that support them,
  • the order of recovery (what we start first, what can wait),
  • roles and decision-makers together with contact details,
  • step-by-step technical recovery procedures,
  • criteria for declaring a situation a disaster and triggering the plan.

Start with a business impact analysis

Before you calculate anything technical, answer the business question: which processes must run for the company to earn money and not break contracts. This is the Business Impact Analysis.

For each process, establish:

  1. how long the company will survive without it before real losses appear,
  2. which systems and data it needs,
  3. who owns the process and who has to be notified.

Only from this analysis do the technical parameters follow. Without it, it is easy to spend a lot of money recovering a system that could safely have waited a day.

RTO and RPO, the hard numbers of the plan

Two parameters hold the whole DR plan together and must be set for each system separately.

  • RTO is the maximum acceptable time to restore a service. How many hours the company can hold out without a given system.
  • RPO is the maximum acceptable data loss measured in time. How much work you can lose because it falls between copies.

A file server might have an RTO of eight hours, while an invoicing system has one hour. These numbers translate directly into the cost of the solution and the frequency of copies.

A sentence about a four-hour RTO sounds good in a meeting. The problem starts when I ask who will start the recovery at two in the morning and whether they have the passwords for it. A DR plan without assigned people is just a wish.

Design failure scenarios

There is no point writing a plan for one abstract disaster. It is worth setting out several realistic scenarios, because they differ in response:

  • failure of a single server or storage array,
  • a ransomware attack that encrypts production and network resources,
  • loss of an entire location, for example a fire or flooding of the server room,
  • failure of a cloud provider or the internet link.

For each scenario, describe the alarm signal, the decision-maker and the first three steps. Ransomware is especially important here, because it requires isolating the environment before you start restoring anything. Restoring data into an infected network is a repeat of the disaster.

Infrastructure that supports recovery

A DR plan needs a backbone. In practice this most often means:

  • copies in the 3-2-1 model with one immutable copy off-site,
  • a second location or cloud you can switch key services to,
  • virtualisation, thanks to which you restore a server as a machine rather than assembling hardware from scratch,
  • up-to-date documentation of the network, addressing and dependencies between systems.

The better the dependencies are described, the lower the risk that after restoring the database it turns out the application will not start because a directory service is missing.

A test is the only proof the plan works

A disaster recovery plan no one has rehearsed is worth as much as an untested backup. A test uncovers gaps invisible on paper: outdated passwords, missing licences, the wrong start-up order.

I recommend three levels of tests:

  1. a dry-run review of the document with the team, several times a year,
  2. restoring a selected system in a test environment,
  3. a full exercise of switching key services over at least once a year.

After each test, update the plan. The IT environment is alive, and a plan from a year ago often describes a company that no longer exists.

Where to start

If you are starting from scratch, do it in this order:

  1. list critical processes and assign them an RTO and RPO,
  2. check whether the current copies even let you meet these parameters,
  3. describe two or three failure scenarios and the first response steps,
  4. designate the responsible people and record contact details,
  5. schedule the first restore test in the calendar.

Building a mature plan requires combining knowledge of the business with hard technology. If you want to build on a proven pattern, see how we deliver disaster recovery and server backup. I will happily review your current copies with you and show where the plan has gaps, before a failure does it.