When people talk about backups, the discussion almost always focuses on the tool: which software, which storage, how often. But the right question comes first and is not technical: how much can you afford to lose? Two acronyms help answer it precisely, and everything else follows from that answer.
The two measures
RPO: how much data you can lose
The Recovery Point Objective is the maximum amount of data it is acceptable to lose, expressed in time. An RPO of 24 hours means that, after a disaster, you can restart from yesterday's data. An RPO of five minutes means you accept losing at most the last five minutes of work.
RPO determines the frequency of copies. With a nightly backup, the real RPO is up to 24 hours, because a failure at 11 pm loses the whole day.
RTO: how long you can be down
The Recovery Time Objective is the maximum time within which the service must be operational again. An RTO of four hours means that, from the moment of failure, users must be able to work again within four hours.
RTO determines the architecture of recovery: ready-to-use copies, standby servers, automation, documented procedures.
Each service has its own targets
The most common mistake is setting a single target for everything, usually "zero loss and zero downtime". It is an unrealistic and expensive target. A serious analysis starts from the list of services and asks, for each one, what happens if it stops.
| Service | Impact of an outage | Reasonable RPO | Reasonable RTO |
|---|---|---|---|
| Online shop | Sales lost immediately | Minutes | An hour or less |
| Order management | Work blocked | An hour | A few hours |
| Brochure website | Image, no direct loss | A day | A day |
| Historical document archive | Low in the short term | A day | Several days |
The values in the table are examples, not rules: they depend on the type of business. The point is that each row requires different solutions, at very different costs.
From targets to architecture
The tighter the targets, the more complex the solution. The classic strategies, in increasing order of cost, are four.
- Backup and restore: periodic copies kept elsewhere. In a disaster you recreate the infrastructure and restore the data. It costs little, but RTO is measured in hours or days.
- Pilot light: data is continuously replicated to another region or provider, but application servers are off or reduced to a minimum. In a disaster they are started and scaled up. RTO of tens of minutes or a few hours.
- Warm standby: a reduced but working copy of the whole system is always running elsewhere. You just increase its resources and move the traffic. RTO of minutes.
- Active-active: the system runs simultaneously in several locations, each able to carry the load. A failure at one location is absorbed by the others. RTO close to zero, but high complexity and cost, especially to keep data consistent.
For RPO the logic is similar: from daily backups you move to hourly backups, then to continuous replication of database logs, up to synchronous replication, which however slows down every write.
The written plan
A disaster recovery plan is not a list of good intentions, but an operational document that someone must be able to follow under pressure. It should contain:
- the list of services with their RPO and RTO and the dependencies between them;
- where the backups are, how to access them and where the necessary keys and passwords are kept;
- step-by-step recovery procedures, in the correct order: first network and DNS, then databases, then applications;
- who decides to activate the plan and who carries out each part, with backup contacts;
- how to communicate with users and customers during the emergency.
The plan must also be kept outside the infrastructure it describes. A document saved only on the server that has just failed is of no use to anyone.
Test, measure, correct
The only way to know whether the targets are achievable is to simulate a disaster. A test can be simple: restore the production database in an isolated environment and time the operation. Or more complete: recreate the whole service in another region starting only from the written plan and the backups.
Tests always reveal something. A password nobody remembers, a step taken for granted, a restore that takes twice as long as expected. In my work I prefer an imperfect test every six months to a perfect plan never tested. After each test the document should be updated with what was learned.
In short
- RPO measures how much data you can lose and determines how often you copy.
- RTO measures how long you can be down and determines the recovery architecture.
- Set different targets for different services, based on the real impact of an outage.
- Strategies range from backup and restore to active-active, at increasing cost.
- A written plan, kept elsewhere and tested regularly, is the only concrete guarantee.
