Recovery objectives
A Socratic walk-through of recovery objectives — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #Why does planning for disaster start with deciding how much data you are willing to lose?
Ask someone to plan for a disaster and they will usually start with the disaster: fire, flood, a region going dark, a careless DELETE. But the practitioners' first question is stranger and colder. Before anyone asks what might go wrong, they ask: how much of your data are you willing to lose? Not "would you like to lose data" — the assumption is that you will, and the only open question is how much.
Why start there? It sounds like giving up before the fight. It is worth working out why that particular question, asked first, does more useful work than any list of hazards.
Reasoning it through
REASONING #Start by noticing what "recovered" even means. To bring a system back you need two things: a copy of the data as of some moment, and somewhere to run it. Those are separable, and they fail differently.
Take the copy first. However you make it — a nightly dump, a snapshot every hour, a replica fed continuously — there is always a most recent good copy, and it is always slightly behind the live system. So there is a window between the last copy and the moment of failure, and everything written in that window is gone. That window has a name: the recovery point objective, the RPO. It is measured in time, but what it really names is a quantity of lost work.
Now ask the useful question. Can the RPO be zero? Only if every write is durably in two places before it is acknowledged — synchronous replication. That is buildable, and people build it, but it means every write waits for the slower of two systems, and if those systems are far apart the speed of light is in the loop. So an RPO near zero is not bought with cleverness; it is bought with latency on every single write, forever, including the overwhelming majority of days when nothing is wrong.
That is the first reason the question comes first. The RPO is not a recovery decision at all — it is a decision about how the system runs normally. Choose "we can lose fifteen minutes" and periodic snapshots suffice. Choose "we can lose nothing" and you have just specified the write path of the whole application. You cannot bolt that on afterwards.
Now the second thing: somewhere to run it. Having a perfect copy on tape does not help if restoring it takes two days. The time from failure to service restored is the recovery time objective, the RTO. And notice it is governed by different machinery: standby capacity, how automated the failover is, how fast a restore streams, how long it takes a cold cache to warm.
So the two objectives are close to independent, which is the part people miss. A legal archive may need to lose nothing and can be down for a day. A session cache can lose everything and must be back in seconds. Those are opposite requirements, and if you had only one number for "how important is this system" you could not express either of them.
There is a third quantity that quietly ruins plans: detection time. RTO is usually written as if the clock starts at the failure, but it starts when someone notices. Silent corruption replicated to the standby is the classic case — the replica faithfully copies the damage, so a system with an RPO of zero can still need the backup from before the corruption. That is why replication and backup are not substitutes, and why retention — how far back you can go — is a separate question from both objectives.
One honest caveat: these are objectives, not guarantees. What you actually achieve in an incident is often called the recovery point or time actual, and the gap between the two is only discovered by rehearsing. An untested restore procedure is a hypothesis, not a plan.
The analogy
THE ANALOGY #Think of it like deciding how often to save a document you are writing. Autosave every keystroke costs a little responsiveness on every keystroke of every day; saving each hour costs nothing until the power cuts, and then costs an hour. Neither is right in the abstract — what settles it is how much of an hour's writing you could bear to redo, which you must decide before choosing the autosave setting, not after the lights go out.
a document is one person's work, so redoing it is merely tiresome, whereas lost transactional data often cannot be reconstructed at all — nobody remembers which payments were accepted — so the loss is not "redo the work" but "the record of what happened is gone."
Clarifying the model
THE MODEL #Three refinements.
First, RPO and RTO are budgets, not wishes. Everyone's instinct is zero and zero; the discipline is that both numbers have a price paid continuously, so they must be argued against the cost of the loss they prevent. That argument is per system, not per company — a single organisational RPO is a sign the exercise was skipped.
Second, the objectives are inputs to architecture, not outputs of it. The RPO fixes the maximum interval between durable copies, which fixes the replication scheme. The RTO fixes how much standby capacity must sit ready, which fixes the bill. Read the other way, an existing backup schedule already implies an RPO whether or not anyone chose it — worth computing, because it is often a surprise.
Third, tiering beats a single answer. Most systems contain data of several kinds: a ledger that must not lose a row, a derived index that can be rebuilt from it, a cache that can be discarded. Assigning one strict objective to all of them buys expensive protection for data you could regenerate for free.
A picture of it
THE PICTURE #How to readThe horizontal axis is the RPO question — how much data you can bear to lose — and the vertical axis is the RTO question — how long you can bear to be down. They are drawn as separate axes because they genuinely are separate: the session cache sits far left and high, the legal records far right and low, and neither could be described by a single "importance" score. The label in each corner is the architecture that corner implies, which is the point of asking both questions before designing anything.
What became clearer
WHAT CLEARED #Planning starts with acceptable data loss because that number, and only that number, dictates how the system must behave on an ordinary day. Recovery time can largely be bought later with standby capacity and automation; recovery point cannot, because it is decided by the write path. Naming the two tolerances separately, per class of data, turns an unbounded conversation about hazards into two priced budgets — and then makes the plan testable, since both are claims that a rehearsal can falsify.
Where to go next
ONWARD #- How retention windows interact with corruption that replicates faithfully to every standby.
- What a game day or restore rehearsal actually measures, and why achieved figures drift from the objectives.
Key terms
TERMS #| Term | What it means |
|---|---|
| RPO (recovery point objective) | the maximum amount of data, expressed as a time window, that the business accepts losing in a disaster. |
| RTO (recovery time objective) | the maximum acceptable time between failure and restored service. |
| Synchronous replication | acknowledging a write only after it is durable in more than one place; drives RPO toward zero at the cost of write latency. |
| Retention | how far back in time recoverable copies exist, which limits recovery from damage discovered late. |
Every term the collection defines is gathered in the glossary.