Contents8
A server that will not restart, a cloud account locked, a command that wipes what it should not, a data centre on fire. The day it happens, the question is no longer technical: it is knowing what to restart first, with what, and who decides. If the answer is written down nowhere, it gets improvised under pressure, and that is when the hours stretch out.
This guide from our Infrastructure and cloud section describes what a disaster recovery plan must contain, the two figures management must set, and how to know it works before you need it.
In short
Business continuity means continuing to operate, often in a degraded mode; recovery means restarting what has stopped.
Two figures per service: the acceptable downtime and the acceptable data loss. That is a management decision, not a technician’s.
The plan says what to restart, in what order, with which backups, with what access, and who to notify.
A plan that has never been tested is a hypothesis: a real restore gives the true delay.
Continuity, recovery: what are we talking about?
The French data protection authority, the CNIL, draws a clear line between the two in its guidance on business continuity and recovery: ensuring continuity means planning ways to keep operating, usually in a degraded mode; recovery covers all the actions needed to restart a system that has stopped. It recommends writing a business continuity plan and a disaster recovery plan, even brief ones, with the list of people involved.
This article covers the second. A disaster recovery plan does not require a hundred-page binder: for a company of 20 to 500 people, a few precise pages are worth more than an exhaustive document nobody opens.
Why write it in advance
Because a disaster gives no warning, and it can take more than a server with it. On 10 March 2021 at 00:47, a fire broke out in one of OVHcloud’s four data centres in Strasbourg. According to the host’s statement, the fire destroyed the SBG2 building and kept threatening the neighbouring data centres until firefighters brought it under control.
That day, a plan that assumed the data centre still existed was of no use. A useful plan answers the question: if this place disappears, where do we restart from? That is why the 3-2-1 backup rule calls for a copy at another site, as our guide to backing up your own server explains.
The most frequent disasters are more mundane, though: a human error, an update that breaks something, a compromised account. We have lived through one.
From the field
On 5 July 2026, a badly targeted clean-up command destroyed the containers of ten services on our own server in one go. The data, kept in separate volumes, was saved, and the services were rebuilt. What this incident taught us fits in one sentence: what saves you is not being careful, it is having written down beforehand what you rebuild and how. Our operating rules are now written down, including those that govern destructive commands.
The two figures management must set
Definition
Acceptable downtime (RTO)
The length of time a service can remain in recovery before the outage harms the business. NIST calls it the recovery time objective, in its publication SP 800-34.
Definition
Acceptable data loss (RPO)
The point in time to which data must be recovered after an outage, in other words how much recent work you accept to lose. NIST calls it the recovery point objective, in the same publication.
These two figures are set service by service, and it is not up to the technician to choose them: they commit the business, so management. Can the CRM stop for half a day? Can you lose the morning’s data entry, or only the last five minutes? The answer decides everything else: a nightly backup means at best a day’s loss, and a recovery time of a few minutes requires a second system ready to take over, which has a cost.
Key takeaway
The smaller the two figures, the more recovery costs. Setting them means deciding how much the company is willing to pay not to stop.
What the plan must contain
- The inventory of services, in recovery order.
For each one, its acceptable downtime and data loss, and what it depends on: you do not restart the CRM before the database it uses.
- Where the backups are, and how to restore them.
For each service: the location of the copies, the restore command or procedure, and how to check that the result is good.
- Emergency access.
The credentials needed for recovery, kept outside the system that can fail: a secrets vault reachable even if the main server is lost, and at least two people able to open it.
- Who does what, and who to notify.
Who decides to trigger the plan, who restores, who informs teams, customers and, where relevant, the authorities. The CNIL asks that users, providers and subcontractors know who to alert in the event of an incident.
- Degraded mode.
How the business carries on during recovery, without lowering data security: the CNIL explicitly warns against this risk.
- Return to normal.
How you get back to the usual situation, and what you check before declaring the incident closed.
The third point is the one most often missing. A perfect plan whose passwords sit on the destroyed server is useless.
From the field
On Palmora Property, a property portal we operate, it was the dependence on a single machine that led to a self-hosted secrets vault. Backups go off the server, for about 6 dollars a month, and a restore there is judged on the number of tables and records recovered, not on the tool’s exit code, which reports an error on mere warnings.
How to know the plan works
By testing it. The CNIL lists among the mistakes to avoid not testing continuity or recovery measures in advance, and recommends regularly testing the restoration of backups and the application of the plan.
Two complementary exercises:
- the tabletop exercise, at least once a year: the team walks through the plan out loud on a scenario (“the main server is lost, it is 9 a.m. on a Monday”) and notes every gap;
- the real restore, every quarter for critical services: a service restored in a disposable environment, timed, and validated on its content.
The time measured during the real restore is your true recovery time. If it exceeds the downtime set by management, one of the two has to change: the figure, or the means.
The plan within the rest of the infrastructure
The recovery plan relies on everything around it: tested backups, monitoring that raises the alarm before customers do, an infrastructure foundation with shared rules. The choice of hosting shapes it too: on a single server, recovery means restoring; with a second server or managed services, it means failing over, as dedicated server, VPS or cloud and Kubernetes: when a mid-sized company does not need it explain. Every level of redundancy has a price, found in the five items that inflate a cloud bill.
Continuity is also one of the objectives of the framework ANSSI is preparing for NIS2, detailed in NIS2 in France: the law still not passed. The other articles in the section complete the picture: which tools to move out of SaaS first, the three-year cost of leaving SaaS, self-hosted n8n in production, cloud migration without breaking things and dependence on the American cloud.
Where to start
Bring management and the person who runs your systems together for an hour. List the services, set the two figures for each, then check that the existing backups make it possible to meet them. Then write the six sections above, even one page each, and schedule the first real restore.
If your tools run on a server of your own, our Leaving SaaS offer comes with off-server backups, a tested restore and operating documentation that says how to restore and who to notify. For emergency access, the AI secrets vault keeps your passwords and keys in a vault opened in your name. For a plan on existing infrastructure, tell us about your services.
Frequently asked questions
What is the difference between a business continuity plan and a disaster recovery plan?
The business continuity plan sets out how to keep operating during an incident, often in a degraded mode. The disaster recovery plan describes how to restart what has stopped. The CNIL recommends writing both, even in brief. For a mid-sized company, the recovery plan is often the first to write, because it builds on backups that already exist.
What do RTO and RPO mean?
The RTO, recovery time objective, is how long a service can stay down before the business suffers. The RPO, recovery point objective, is the point in time to which data must be restored, so the amount of recent work you accept to lose. Both are set service by service, by management, and decide which kind of backup and redundancy to pay for.
How often should a recovery plan be tested?
The CNIL asks for regular testing, without setting a rhythm. We recommend a tabletop exercise at least once a year, and a real restore every quarter for critical services, timed and validated on content. The right rhythm remains the one the team actually keeps: a test that is done is worth more than a test that is planned.
Does a small company need a disaster recovery plan?
Yes, on its own scale. As soon as a tool is essential to the business, you need to know how to restart it and who does it. For a small organisation, a few pages are enough: the list of services, the two figures for each, where the backups are, the emergency access and the people to notify. What matters is that it is written, reachable and tested.
Sources
- CNIL, Security: plan for business continuity and recovery (in French) (new tab)cnil.fr
- OVHcloud, statement on the fire at the Strasbourg site, 10 March 2021, in French (new tab)community.ovhcloud.com
- NIST glossary, recovery time objective, from SP 800-34 Rev. 1 (new tab)csrc.nist.gov
- NIST glossary, recovery point objective, from SP 800-34 Rev. 1 (new tab)csrc.nist.gov
CNIL, Security: plan for business continuity and recovery (in French)
Read on cnil.fr(new tab)OVHcloud, statement on the fire at the Strasbourg site, 10 March 2021, in French
Read on community.ovhcloud.com(new tab)NIST glossary, recovery point objective, from SP 800-34 Rev. 1
Read on csrc.nist.gov(new tab)Jim · founder of Brain Plus AI
Also in infrastructure and cloud
Practical guide7 min
Backing up your own server: what really breaks
Everyone knows the 3-2-1 rule, but what loses data is more mundane: a backup never restored, a forgotten volume, a global clean-up command run in production. Here is what we learned from operating our own server.
Practical guide7 min
Monitoring: knowing a service is down before customers do
An outage discovered by a customer costs twice: the lost service, and the trust. What monitoring should watch, from the outside as well as the inside, who should receive the alert, and how to avoid the one nobody reads any more.
Practical guide6 min
NIS2 in France: the law still not passed, what to do
Two years after the European deadline, the law that transposes NIS2 in France was again withdrawn from the National Assembly's agenda on 6 October 2026. Where the bill stands, who will be covered, and the measures that protect you now, whatever the date of the vote.