A backup does not guarantee continuity. It can be incomplete, inaccessible during an attack, take too long to restore, or depend on a service that is itself unavailable. The business recovery plan transforms business objectives into procedures, technical means, and measurable exercises.
The BCP, business continuity plan, seeks to maintain a level of service during disruption. The DRP, disaster recovery plan, organizes recovery after an interruption. For a web application, both cover the code, data, infrastructure, third-party services, teams, and business validation.
Start from the business impact
The initial question is not "how many backups do we want?", but "what happens if this path is unavailable or if its latest data disappears?". The impacts can be financial, operational, contractual, regulatory, or reputational.
Each capability is classified: consultation, entry, payment, calculation, import, notification, administration. Some can operate in degraded mode; others require a shutdown to protect integrity.
This analysis defines the recovery priorities. Restoring the entire site before the function that receives orders may be technically comfortable but professionally incorrect.
Understanding RTO, RPO, MTPD, and WRT
The RTO is the target time between the interruption and the recovery of the technical service that is acceptable. The RPO represents the maximum amount of data that the organization is willing to lose, expressed in time.
The MTPD refers to the maximum tolerable period of disruption before the consequences become unacceptable. The WRT, or work resumption time, covers what business teams must do after the technical recovery: checks, reconciliations, catch-up, and communication.
A simple consistency is required: the RTO plus the WRT must remain below the maximum tolerable delay. The RPO must be compatible with the backup or replication frequency actually achieved.
The timeline starts from the backups available before the incident. The period between the last recoverable point and the incident represents the data loss defined by the RPO. After the incident, the RTO covers the decision, reconstruction, and restoration until the return of an acceptable technical service. The WRT extends this duration until validation and the full resumption of work by the business teams. The total of RTO plus WRT must remain below the MTPD, the maximum tolerable period of disruption.
A complete backup strategy
A precise strategy:
- the covered data;
- frequency;
- retention;
- offline or immutable copies;
- the separation of accounts and rights;
- encryption;
- monitoring failures;
- the restoration procedure;
- the test evidence.
The so-called 3-2-1 rule — multiple copies, on separate media, with one offsite — constitutes a starting point, not a universal guarantee. Backups must include databases, files, configurations, necessary keys, and compatible code versions.
Restore the coherent whole
A restored database without the associated files, or recent code with an old schema, can make the application inconsistent. The DRP defines a point of consistency and the order: infrastructure, secrets, database, storage, indexes, workers, caches, and services.
Migrations and scripts must be versioned. Encryption keys and certificates necessary for reading data are protected separately but available during the crisis.
Choose the emergency level
Backup and reconstruction
Suitable when the RTO is measured in hours or days. The infrastructure is recreated and then the data is restored. This approach is cost-effective but depends on automation and the availability of components.
Cold or lukewarm backup environment
Resources are prepared, with part of the infrastructure or data already available. The cost increases, the recovery time decreases.
Hot backup and replication
A ready infrastructure receives data continuously or almost continuously. The switchover can be quick, but one must manage error replication, conflicts, and rollback testing.
Active continuity
Several zones or sites serve the traffic. This architecture aims for high availability, without eliminating the need for backups: a logical deletion or a compromise can spread everywhere.
Mapping dependencies
The application often depends on DNS, identity, email, payment, storage, business APIs, and providers. The business continuity plan must specify the behavior of each: waiting, queuing, degraded mode, another provider, or controlled suspension.
Redundant architecture loses its value if the DNS account, the identity provider, or a unique key remains a single point of failure. Organizational dependencies also matter: who can access the accounts, make a decision, and communicate?
Define crisis scenarios
A generic plan is not enough. Test scenarios:
- deletion or corruption of data;
- unavailability of a cloud region;
- compromise of administrator accounts;
- ransomware ;
- certificate or expired domain;
- defective deployment;
- failure of a third-party service;
- unavailability of a key person.
Each scenario specifies trigger, scope, decision, isolation, restoration, validation, and crisis exit.
Write a runbook usable under pressure
The runbook must be short, versioned, and accessible even if the main system is unavailable. It lists the contacts, prerequisites, commands, expected results, and stop points. Secrets are not written in plain text; their vault and access procedure are tested.
The roles are separated: crisis management, technical intervention, business validation, communication, and liaison with suppliers. The same person can take on multiple roles in a small organization, but responsibility remains explicit.
Test the restoration
A backup test checks that a file exists. A restore test proves that it can be used. The exercise must measure:
- access recovery time;
- reconstruction time;
- transfer and restoration time;
- integrity checks;
- validation of pathways;
- deviations from RTO/RPO;
- manual operations and errors.
The exercises can start with a table, then an isolated environment, then a complete repetition. They must produce actions with deadlines.
Prepare the communication
Continuity includes users, partners, and teams. Message templates explain what is known, the impact, the measures, and the next update. Unconfirmed timing promises should be avoided and security information protected.
A timestamped crisis log records decisions, actions, and evidence. It facilitates feedback and any reporting obligations.
Keep the plan alive
The DRP is reviewed when the architecture, volumes, suppliers, or organization change. Contacts expire, orders evolve, and business objectives become stricter. An annual review is the minimum for an important platform; tests may be more frequent depending on criticality.
The indicators track the success rate of backups, the age of the last test, the measured recovery time, the gaps, and the unfinished actions.
A skill, not a document
The level of continuity must be proportional. An RTO of a few minutes implies an expensive architecture and organization. An objective of several hours can be perfectly acceptable if it is assumed and tested.
Partitech provides hosting, IT management, monitoring, and maintenance of digital platforms. We can map dependencies, define objectives, automate restoration, and conduct exercises so that the disaster recovery plan corresponds to actual capacity.
To deepen the approach, frame the service levels and application maintenance, start with a technical audit of the application and prepare them application failover strategies. Also discover the offer Maintenance, developments, hosting and IT management from Partitech.
Official references
References consulted on August 17, 2026: