A backup and disaster recovery (DR) plan is not measured by how many copies are made, but by how long it takes the organisation to get back to operating after an incident and how much data it loses along the way. Those two questions have technical names — RTO and RPO — and they are the starting point of any serious design. In this article we develop the complete methodology: from impact analysis to automatic failover, with the 3-2-1-1-0 rule, defence against ransomware and the recovery tests that separate a real plan from a decorative document.
RTO and RPO: the two metrics that govern everything
The RTO (Recovery Time Objective) is the maximum acceptable time a system can be down after an incident before causing unbearable damage to the business. The RPO (Recovery Point Objective) is the maximum amount of data, measured in time, that the organisation can afford to lose; an RPO of one hour means that, in the worst case, up to one hour of transactions will be lost. Both are derived from the Business Impact Analysis (BIA), which classifies each system by its criticality.
The technical consequence is direct: an RPO of five minutes is not covered by a nightly backup, it requires near-continuous replication; an RTO of fifteen minutes is not covered by restoring from tape, it requires a hot standby system. Defining RTO and RPO system by system is what avoids the dual mistake of overspending to protect the irrelevant or falling short on the critical. These metrics are also an explicit requirement of the ISO 22301 business continuity standard and of the backup control in ISO/IEC 27001:2022.
The 3-2-1 rule and its 3-2-1-1-0 evolution
The classic 3-2-1 rule states: three copies of the data, on two different types of media, with one copy offsite. It is the civilised minimum. The ransomware era has demanded that it be hardened into 3-2-1-1-0: the additional first "1" requires an immutable or air-gapped copy (isolated from the network), and the "0" requires zero errors in the verification of the copies. A copy that has not been verified is not a copy: it is an assumption.
Immutability is implemented with object lock technologies in object storage or with WORM (Write Once Read Many) repositories. The reason is that modern ransomware actively seeks out and encrypts backup repositories before detonating; if the copy cannot be modified or deleted during its retention period, the attacker cannot disable it. The air gap, physical or logical, adds a second barrier by disconnecting the copy from the production network.
Types of backup: full, incremental and differential
The full backup copies all the data every time; it is the simplest to restore but the most costly in space and window. The incremental backup copies only what has changed since the last copy (whether full or incremental); it minimises the backup window but chains dependencies, so that restoring requires the full copy plus the entire chain of incrementals. The differential backup copies what has changed since the last full copy; it takes more space than the incremental but restores in two steps. The usual strategy combines a weekly full backup with daily incrementals or differentials, tuning the frequency to the target RPO.
Two modern techniques refine this classic scheme. The incremental-forever backup performs a single initial full copy and, from then on, only incrementals, periodically synthesising a new full copy in the repository without re-reading all the source data; this drastically reduces the load on the production systems. For its part, deduplication eliminates repeated blocks before storing them, so that an identical piece of data present on a thousand machines is stored only once, with saving ratios that in virtualised environments frequently exceed 90%. Both techniques cut the cost of long retention, but they introduce a critical dependency: if the base full copy or the deduplication index becomes corrupted, the entire chain is compromised, which reinforces the need for periodic verification.
A final concept to plan for is tiered retention (GFS, Grandfather-Father-Son): daily copies kept for a few weeks, weekly copies kept for months and monthly or annual copies kept for years. This scheme balances the ability to roll back to a recent point with the legal or business obligation to keep long-term milestones, and it must be aligned with the retention policies imposed by the GDPR for personal data.
Replication and failover: from copy to continuity
Backup protects the data; replication protects the service. Synchronous replication writes to the primary site and to the secondary before confirming the transaction, which guarantees an RPO of zero but imposes a maximum distance because of latency. Asynchronous replication confirms at the primary and propagates to the secondary with a small lag, which allows large geographical distances in exchange for an RPO of seconds or minutes.
Failover is the mechanism that switches operation to the secondary site when the primary goes down. It can be manual, assisted or automatic. Automatic failover with an RTO of minutes requires a hot standby site, load balancers that redirect traffic and a replicated, promotable database. Just as important is failback: the procedure for returning to the primary site once restored, without losing the data generated at the secondary during the contingency. Many plans design the failover and forget the failback, and discover the problem at the worst possible moment.
DR strategies by budget and criticality
| Strategy | Typical RTO | Typical RPO | Relative cost |
|---|---|---|---|
| Backup & restore | Hours to days | Up to 24 h | Low |
| Pilot light | Tens of minutes | Minutes | Medium-low |
| Warm standby | Minutes | Seconds to minutes | Medium-high |
| Multi-site active-active | Near zero | Near zero | High |
The choice is not an aesthetic preference: it is deduced from the RTO and RPO that the BIA set for each system. An ERP that issues invoices does not allow the same level as an internal documentation portal, and mixing the two in the same strategy means wasting money or assuming unacceptable risk.
Recovery tests: what truly distinguishes a real plan
An untested DR plan is documentary fiction. The tests must be periodic and tiered: a tabletop review (on paper, validating roles and decisions), partial restoration tests of specific systems and, at least once a year, a full failover drill that switches production to the secondary site. The metric being validated is twofold: that the real RTO does not exceed the objective and that the integrity of the restored data is 100%. ISO 22301 requires these exercises to be documented and the lessons learned to be recorded.
A frequently forgotten detail: the recovery procedure must be available outside the systems it protects. If the DR instructions live only on the file server that has just gone down, the plan has sabotaged itself.
Backup and the GDPR: the legal dimension
Backups contain personal data and are therefore subject to the GDPR. This implies encrypting the copies in transit and at rest, controlling access to the repositories and applying retention policies consistent with the principle of storage limitation. The right to erasure (the "right to be forgotten") poses a technical challenge: when a data subject exercises their right, the historical backups will keep the data until they expire; the solution accepted by the Spanish Data Protection Agency is to document the impossibility of selective deletion in backups and to guarantee that the data will not be reintroduced if an old copy is restored.
Common mistakes in backup and DR plans
- Not testing the restore: the backup looks fine until you try to restore and it fails.
- A single online copy: without an immutable or offline copy, ransomware encrypts the backups too.
- RTO/RPO without a BIA: objectives set by intuition that do not respond to the real impact.
- Forgetting failback: you switch to the secondary and there is no clean way back.
- Unencrypted copies: legal and exfiltration risk to the backup repository.
Frequently asked questions
How often should I make backups?
The frequency is dictated by the RPO of each system. If the business cannot lose more than one hour of data, the backups or replication must cover that window; there is no universal number valid for all systems.
Does the cloud make a DR plan unnecessary?
No. The cloud facilitates geo-redundancy, but the shared responsibility model leaves the backup of the data and the DR configuration in the customer's hands. A configuration error or an accidental deletion is not covered by the provider.
What is an immutable copy and why does it matter?
It is a copy that cannot be modified or deleted during a defined period. It matters because it neutralises the ransomware attack against the backups themselves, which is today one of the most common tactics.
How often should the DR plan be tested?
At least once a year with a full drill, and quarterly with partial restoration tests. After any major infrastructure change it is wise to repeat the test.
Conclusion
A robust backup and recovery plan is built the opposite way to how it is usually done: first you decide how much downtime and how much data loss the business tolerates (RTO and RPO per system), and only then do you choose the technology that meets those numbers at the lowest cost. The 3-2-1-1-0 rule, the immutable copy against ransomware and, above all, periodic restoration tests are what turn a set of copies into a genuine continuity capability. At Summum Systems we design DR plans always starting from the BIA and we validate them with real drills, because the only backup that counts is the one proven to restore, and the only plan that is worth anything is the one already executed at least once before the real incident.