IT disaster recovery plan (DRP): the method, and what a real disaster says about it
A disaster recovery plan answers a single question: if you lose your server room, your hosting provider or your data tomorrow, how do you restart, how long does it take, and what do you lose? The five steps to answer it in writing, before the disaster, then what a real case says about it.
Contents
1. DRP and BCP: the difference
The DRP: restarting after the stop
The disaster recovery plan accepts an interruption. It sets its maximum duration, how much data you accept to lose, and the sequence of actions that brings the service back: where to restore, in which order, who decides.
The BCP: not stopping at all
The business continuity plan tries to avoid the stop, with an architecture that fails over on its own to a second site or a second node. That is the ground of high availability, and its budget is not the same.
A BCP does not replace the DRP. Replication also copies what does damage: a deletion, a botched migration, files encrypted by ransomware. Even with perfect continuity, you need a way back to a clean state. That is why the rest of this page is about the DRP.
2. RTO and RPO: setting what you accept to lose
Two figures, set by the business rather than by IT, size everything else.
RTO: how long without the service?
The Recovery Time Objective is the maximum downtime you accept. It decides the method: in hours, a restore from backup may do; in minutes, you need an infrastructure ready to take the load.
RPO: how much data lost?
The Recovery Point Objective is measured in time: an RPO of 24 hours accepts losing the last day. It decides how often you back up, or replicate when a daily backup is not enough.
Set them per application, not for the whole infrastructure: accounting, email and the public website have neither the same cost of downtime nor the same value for their last hour. The shorter both figures, the more the architecture costs; the RPO / RTO calculator helps weigh that cost against the cost of an hour of downtime.
An RTO remains an objective. Only the duration measured during a real restore (section 5) tells you whether it holds.
3. Mapping your dependencies: who can cut you off?
A service does not only go down when its server does. List, for each application, everything it needs to run, and spot what exists only once.
Power
UPS, generator, cooling: what is the real autonomy, and when was it last checked?
Network and carriers
Internet links, site interconnection, DNS. Two links from two carriers are not redundancy if they share the same duct or the same backhaul point.
The hosting provider and the site
A single datacenter, a single building, a single account with the provider: each one is a breaking point. A backup kept with the same provider as production disappears with it.
A single person
The one who knows the passwords, the restart order or the contact at the carrier. If they are on leave the day of the disaster, the plan has to work without them.
A "redundant" supplier often depends on another one
Your provider has two power feeds, but a single energy supplier. Your carrier sells you two links, but rents both from the same backhaul network. Your online tool is "multi-zone", but relies on a single identity provider. For each dependency, ask the question one step further: what does it depend on? We did it for our own network: see the real diversity of our own transit providers (in French). And check that the DRP documentation, the access credentials and the encryption keys are not stored on the system they are meant to restore.
A cluster's arbiter, the witness that settles quorum, is a dependency like any other: if the arbiter and the link between the two halves of the cluster depend on the same building, the cluster loses them together. That is what the fire at a municipal core network site (in French) showed in 2023 (section 6).
4. The scenarios to cover
A DRP is not written against "the disaster" in general. Each scenario calls for a different answer, and a plan that covers only one leaves the others unanswered.
Losing a site: fire, flood
The building and everything in it are gone, local backups included. You need a copy of the data elsewhere, a place to restore it, and a network able to route around the lost site. It is the scenario of the real case in section 6.
A hosting provider outage
The data is often intact but out of reach, for a duration you do not control. The plan has to say up to when you wait, and from when you restore elsewhere: see what to do during a hosting provider outage.
Ransomware
The attacker also goes after the backups they can reach. You need a copy they can neither delete nor encrypt, offline or immutable, with credentials separate from production, and a restore that does not reinstall the attack's entry point. The offsite backup guide covers these options.
Human error
The most frequent and least spectacular scenario: a table emptied, a folder deleted, an update that breaks the application. It needs older versions kept long enough, and a fine-grained restore, of one file or one database, without overwriting everything.
5. Testing your DRP: otherwise it is only a hypothesis
A DRP that has never been tested is only a hypothesis. A backup log saying "OK" proves a copy was written, not that it restores, nor how long it takes.
- A real restore, on a machine that is not production, up to a service that answers, not just files that are present.
- Timed: it is the only honest source for the RTO you can actually hold.
- Dated and written down: what was restored, how long it took, the outcome, and what was missing.
- Repeated after every change of hosting provider, application or backup method.
A test nearly always reveals something other than the backup: a password nobody can find, an encryption key left on the lost server, a start-up order nobody wrote down. For a virtualisation platform, the hands-on implementation is described in Proxmox disaster recovery.
6. Real case: losing a core site
On 28 June 2023, in Mantes-la-Jolie, France, a fire destroyed one of the four core sites of the municipal network, which links around 80 sites. RDEM Systems designed and supported that network from 2016 to 2024. The site also hosted the witness of the virtualisation cluster, and both strands of the fibre loop ran through the building. Redeploying the witness elsewhere gave the cluster back an arbiter, but not its other half: the nodes of the other site had to be brought together where the witness had been redeployed, and the cluster rebuilt.
Nobody thinks about a cluster's arbiter while the site hosting it is still standing. The full account, and what it says about a DRP: fire at a core network site (case study, in French).
7. What RDEM takes care of
The DRP remains yours: you set the RTO and RPO of each application. We keep up what makes it executable on the day it is needed.
- A backup outside your hosting provider: a NimbusBackup volume is included in the managed-service plans (Proxmox VE or PBS client); otherwise, backup is not included.
- Restore tests for eligible customers: a randomly picked virtual machine, one every six months up to five machines, one per quarter beyond that, with a report giving the measured duration.
- Someone who picks up: 24/7 monitoring on every plan, and on-call with a 4h response time (GTI) on the Pro plan or 1h on the Critical plan, 24/7.
What we do not write: a guaranteed recovery time. We commit to the response time, not to the time to restore, which nobody can promise before the diagnosis. The figure we give you is the duration measured during the last test. The day-to-day side: what managed services keep up in a DRP.
8. Frequently asked questions
What is the difference between a DRP and a BCP?
The disaster recovery plan, or DRP, organises the restart after a disaster: it accepts an interruption and sets its maximum duration and how much data you accept to lose. The business continuity plan, or BCP, tries to avoid the stop altogether, with a redundant architecture that fails over on its own. A BCP costs more and does not replace the DRP: replication also copies a deletion or a ransomware encryption.
Is a disaster recovery plan mandatory?
No text requires one from every company. The NIS2 directive asks the entities it covers for business continuity measures, including backup management and disaster recovery, and the DORA regulation does the same for the financial sector. For everyone else the question is economic: what does a day of downtime cost, and how long would it take to restart without a plan.
Does high availability replace a disaster recovery plan?
No. A cluster or replicated storage protects against hardware that breaks: it faithfully copies everything written to it, including a table emptied by mistake or encrypted files. And if both nodes sit in the same building, a fire takes them together. The DRP covers what high availability does not: losing the site, damaged data, getting back to a clean state.
Is a backup enough as a disaster recovery plan?
No: the backup is the raw material of the DRP, not the plan. The plan says where you restore if the site is lost, in which order, with which access and who decides. Without those answers written down in advance, an intact backup can stay unusable for days, for lack of a machine to receive it or a key to decrypt it.
How often should a disaster recovery plan be tested?
At a frequency set in advance and kept to, and after every architecture change: new hosting provider, new application, new backup method. The test that counts is a real restore, timed and dated, not a read of a backup log. For eligible customers, we restore a randomly picked virtual machine, one every six months up to five machines and one per quarter beyond that, with a report.
Does RDEM guarantee a recovery time?
No. We commit to a response time (GTI): 4h on the Pro plan, 1h on the Critical plan, 24/7. We do not commit to a time to restore, because until the diagnosis is made, no repair time can honestly be promised. The figure we give you is the restore duration measured during the last test, not a guarantee.