Disaster recovery planning that survives a real outage
A disaster recovery plan is only worth something once it has been restored, rehearsed and kept current. This page says what belongs in one, how you set a recovery time objective, and how disaster recovery relates to business continuity planning.
The four numbers a plan rests on
Fill these in per system and you have a plan. Cannot fill them in, and you have a backup.
What goes into a disaster recovery plan
A disaster recovery plan describes how IT comes back after an outage: which systems first, from which copy, by whom, and how you know it is finished.
- A list of systems, in orderNot everything has to come back at once. The plan puts systems in the order the work needs them, and that order comes from the business rather than from the server cabinet. What is not on it comes back later — and everyone knows that in advance.
- An RTO and an RPO per systemHow long it may be down and how much work may be lost. Those two decide what the technology has to do; it does not work the other way round. An hour of RPO asks for something different than a night.
- Where the copy sits and how you reach itA backup you can only reach through the system that is down is not a backup. The plan names the place, the route to it and who holds the keys — including when the network is out and nobody can log in.
- Who does what, with a phone numberRoles rather than names alone, because people go on holiday. Who decides to fail over, who calls the supplier, who informs the organisation. On paper, because in this scenario the intranet is down too.
How we build such a plan
Five steps, in this order. The first two are about the business and the last three about the technology — the other way round you build something nobody needed.
Find out what stops
Which processes stop when a system goes down, and after how long that starts to hurt. We have that conversation with the people doing the work and not only with IT, because the department that complains loudest is not always the one that has to come back first.
Set an RTO and RPO per system
We put the numbers next to what they cost in technology and in effort. Something almost always shifts: an hour of RTO sounds good until you see what it takes, and then four hours turns out to be fine for half the systems.
Build the technology around them
Immutable backups, replication or failover — what fits follows from the numbers above. We set it up and make sure an infected system cannot take the copy with it; that is the scenario most plans come apart on.
Restore, for real
A recovery performed on a separate environment, with the time measured. Only then do you know whether the RTO holds. Nearly every first attempt produces a surprise — a certificate, a licence, an integration nobody had written down.
Rehearse and maintain
Once a year actually throw the switch, and update the plan whenever a system arrives or leaves. A two-year-old plan describes an environment that no longer exists, and you find that out at the worst possible moment.
Disaster recovery and business continuity planning
The terms get used interchangeably and they are not the same. Business continuity planning is about carrying on; disaster recovery is about the IT that has to come back for that.
- Business continuity planning is widerA BCP describes how the organisation keeps going when something fails: people, buildings, suppliers, communication. IT failure is one scenario within it. Without a BCP a disaster recovery plan is a technical document without a client.
- Disaster recovery is the IT partThe disaster recovery plan is the chapter saying how systems come back and how fast. It takes its brief from the BCP: that is where it says how long a process may be down, and the RTO follows from it.
- The fallback without ITFor the hours when nothing runs: where the paper orders are, how customers reach you, who says what. That belongs in the BCP and not with us, but we do ask about it — because an eight-hour RTO is only acceptable if there are eight hours to bridge.
- Reporting is part of itIf the organisation falls under NIS2, a reporting clock runs alongside the recovery. Letting those two blur costs time at the wrong moment; the plan therefore puts them side by side, with who does which.
What we do, and what stays with you
Continuity is not a product you buy. This is the division we stand behind, and the part that belongs with the organisation itself.
- What we doWrite and maintain the plan, set up the backup and the failover, perform and measure the restore, and take part in the rehearsal. In the Netherlands and Belgium we do the on-site work with our own people; we do not subcontract it.
- What we recordWhich copy sits where, when it was last restored and how long that took. That is the material an auditor, an insurer or a regulator asks for, and it is precisely the part that no longer exists if you have to reconstruct it afterwards.
- What stays with youThe decision to fail over, and the judgement about how long a process may be down. That is a choice about the business rather than about the technology; we work out what it costs and what it buys.
- What nobody can promiseThat nothing will go wrong. What is possible is that the outage runs predictably: known order, known duration, known responsibilities. That is the difference between an incident and a crisis.
Does your recovery actually work? The only way to find out is to run it. Call +31 85 060 9347 or email info@itproposal.com and we will walk through what is in place.
Further reading
The pages in this cluster, and what they connect to.
Questions we get about this
The ones that come up most, answered briefly.
What is the difference between a disaster recovery plan and a backup?
A backup is a copy of your data. A disaster recovery plan describes how complete systems come back from it, in what order, within what time and by whom. A backup without a plan leaves you a copy nobody knows the restore time for.
How often should a disaster recovery plan be rehearsed?
At least once a year actually throw the switch, and update it besides with every change that adds or removes a system. A two-year-old plan describes an environment that no longer exists, and you find that out at the worst moment.
Can you write a disaster recovery plan for an environment someone else manages?
Yes. We write the plan, measure the restore and take part in the rehearsal, including when day-to-day management sits with another party. What we do ask for is access to the facts: which copies exist, where they sit and when one was last restored.
Does continuity fall under NIS2?
Continuity is named in the directive’s duty of care, alongside a reporting duty counted in hours. Whether your organisation falls under it is a legal qualification we do not make; what we supply is the technology and the record such a judgement rests on.
Want to know whether your plan holds?
Tell us what runs and what is arranged now. We walk through the systems, put RTOs and RPOs next to them and say which ones will not be met — before an outage says it for us.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.