5.2Backup & disaster recovery plan
The essentials in 30 seconds
- Backing up is not enough: the DRP describes how to recover after a disaster, the BCP how to keep the business running during the incident.
- RTO = maximum recovery time; RPO = tolerable data loss — these two benchmarks size the plan and justify the budget.
- An untested plan is not a plan: restore drills and up-to-date documentation make recovery real, not theoretical.
Running mini-case — Sofiane sketches the payroll DRP
Sofiane, a support technician at a distribution SME in Algiers, notices that the company has backups but no recovery plan. He sketches a minimal DRP for the payroll service, critical at month-end. He reasons in principles: this service tolerates very little data loss, so frequent backups and a short recovery time — without setting a numerical duration, he above all remembers that these objectives are decided with management according to business constraints. He lists what must be restored and in what order, notes who does what, then schedules a restore drill. He turns “we have backups” into “we know how to restart”.
Standalone case for this section: it returns in the course, diagram, script and 48h challenge of section 5.2.
1. From backup to plan
Backing up is necessary but not enough. A disaster recovery plan (DRP) describes how to recover after a disaster (major outage, fire, ransomware): what to restore, in what order, by whom, with which resources. The business continuity plan (BCP) aims to maintain activity during the incident. Sofiane remembers the simple sentence: we move from “we have backups” to “we know how to restart”.
2. RTO and RPO, the two benchmarks
Two objectives structure the plan. RTO (Recovery Time Objective): how long may we take to be back up? RPO (Recovery Point Objective): how much data can we accept losing? A tight RPO requires frequent backups; a tight RTO requires a fast procedure and ready resources. These benchmarks dictate the investment — Sofiane has them validated with management, service by service, without imposing a ready-made value.
3. An untested plan is not a plan
As with backups, a DRP is tested: restore drills, disaster simulations, documentation updates. A plan written once then forgotten fails on the day (outdated contacts, incomplete procedure, unavailable resources). Sofiane therefore schedules regular drills so the plan stays real, not theoretical.
🔎 Concrete example — 🔎 Concrete example — Reasoning RTO and RPO for payroll
Sofiane reasons in principles about a critical service, without imposing a ready-made numerical value:
Tight RPO → more frequent backups (less data lost)
Tight RTO → fast procedure + ready resources (recover faster)
→ these benchmarks are decided with management, service by serviceReading: RPO drives backup frequency; RTO drives recovery speed.
Lesson: without benchmarks defined with the business, you cannot size (or justify) the plan.
Section vocabulary
- DRP
- Disaster recovery plan: how to recover after a disaster.
Simple example: Sofiane sketches the payroll service's DRP.
What it is not: believing backups are enough.
Reflex: DRP = how to recover.
- BCP
- Business continuity plan: keep the business running during the incident.
Simple example: Sofiane plans how payroll runs in degraded mode.
What it is not: confusing continuity (BCP) and recovery (DRP).
Reflex: BCP = keep going during.
- RTO
- Maximum acceptable time to be operational again.
Simple example: Sofiane sets it with management for each service.
What it is not: a delay chosen with no link to the business.
Reflex: RTO = recovery time.
- RPO
- Maximum amount of data we accept losing.
Simple example: A tight RPO pushes for frequent backups.
What it is not: forgetting it and discovering the loss on the day.
Reflex: RPO = tolerable data loss.
- Recovery drill
- A real test that verifies the plan works.
Simple example: Sofiane schedules a payroll restore drill.
What it is not: a DRP written then never tested.
Reflex: test the plan regularly.
In practice — In practice — Sketch a minimal DRP
- Choose a critical service (like payroll at Sofiane's) and determine its benchmarks with the business: recovery time (RTO) and tolerable data loss (RPO).
- List what must be restored and in what order to bring it back (dependencies first).
- Note who does what and which resources are needed during recovery.
- Schedule a restore drill to validate the plan in the field.
Step-by-step script — sketch your plan like Sofiane (8 min)
1) Name a critical service and set its RTO and RPO benchmarks with the business. 2) List the elements to restore and their order, respecting dependencies. 3) Write who does what and the required resources. 4) Date a first restore drill. 5) Note where backups are stored and how to access them without the main system. 6) Reread the plan as if someone absent had to use it.
A useful plan fits on one page per service: clear, ordered, and above all regularly tested.
Copy-paste template — my DRP sheet (one service)
Service: ___ (e.g. Sofiane's SME payroll)
Benchmarks: RTO = ___ (recovery time) · RPO = ___ (tolerated loss)
To restore (in order): ___
Who does what: ___
Resources: ___
Date of last drill: ___
Rule: an untested plan is not a plan.A plan for payroll
Sofiane first targets the payroll service, critical at month-end, with tight benchmarks.
A plan for files
Sofiane covers the sales reps' document share, useful every day.
Maintain during (BCP)
Sofiane plans a degraded mode so distribution keeps running during the incident.
Test, test again
Sofiane schedules regular restore drills rather than a plan written only once.
✓ Best practices
- Define RTO and RPO with the business, service by service, not in the abstract.
- Order restores according to dependencies (the essential first).
- Test the plan through regular drills: otherwise it does not exist.
✗ Common pitfalls
- Confusing “having backups” and “knowing how to recover”.
- Writing a DRP then never testing it.
- Forgetting dependencies and restoring out of order.
Key takeaways
- The DRP describes how to recover; the BCP, how to keep going during the incident.
- RTO = recovery time; RPO = tolerable data loss.
- These benchmarks dictate backup frequency and investment.
- An untested plan fails: regular drills are mandatory.
48h challenge — apply it tomorrow
Like Sofiane, sketch the DRP of ONE critical service: note its RTO and RPO benchmarks with the business, the ordered list of what must be restored, who does what, then date a first restore drill. Write in one sentence what the SME would gain from knowing how to restart.
- I distinguish backup, DRP and BCP.
- I know how to read RTO (recovery time) and RPO (tolerable loss).
- I know why a plan must be tested regularly.
Frequently asked questions
What is the difference between DRP and BCP?
The BCP aims to keep the business running during the incident (fallback solutions, degraded mode); the DRP aims to rebuild and recover afterwards. The two complement each other: keep going as much as possible, then restore completely.
How do I justify the budget of a DRP to management?
By costing an interruption (lost hours, data, reputation) against the cost of the plan, and by translating needs into RTO and RPO. These benchmarks make the investment concrete rather than theoretical — without imposing ready-made values.
What does the RPO of a disaster recovery plan measure?