Designing for resilience: RTO, RPO and standby patterns.

Two numbers should be agreed before a single line of resilience architecture is drawn: the recovery time objective (RTO) — how long a workload can be down before the business impact is unacceptable — and the recovery point objective (RPO) — how much data loss, measured in time, is acceptable if the worst happens. Everything that follows — which standby pattern to build, how to replicate data, what the DR runbook needs to cover — is derived from those two numbers, set per workload with the people who own the business impact. Skip that step and you get the pattern most estates actually have: one resilience posture applied uniformly, expensive where it is not needed and thin where it matters most.

RTO and RPO, in plain terms

RTO answers “how long can this be down?” An order-management system on a 3PL floor might carry an RTO of fifteen minutes — past that, trucks queue and shifts stall. An internal reporting tool might carry an RTO of a working day; nobody escalates if it is back by tomorrow morning.

RPO answers “how much data can we afford to lose?” measured as a span of time between the last recoverable copy and the point of failure. That same order-management system might need an RPO close to zero — losing even a few minutes of picks and allocations is expensive to reconcile by hand. The reporting tool might tolerate an RPO of four hours; last night’s extract is good enough to rebuild from.

Neither number is a technical default. Both are business decisions, workload by workload, and the honest way to set them is to ask the owner of each system what a given outage or data-loss window actually costs — in dollars, in labour, in customer impact — and work backward from there.

The standby patterns, and what each one costs you

Once RTO and RPO are set, the standby pattern follows. The patterns sit on a spectrum: tighter recovery objectives buy less downtime and less data loss, at the cost of standing infrastructure that sits mostly idle, waiting.

Active-active	Two or more sites serve live traffic at the same time. Near-zero RTO and RPO. Highest steady-state cost and the most operational complexity to keep data consistent across sites.
Hot standby (active-passive)	A fully provisioned, continuously replicated standby, idle until failover. Low RTO and RPO. Pays for full infrastructure it rarely uses.
Warm standby	A scaled-down version of the environment runs at all times and scales up on failover. Moderate RTO. Lower steady-state cost than hot standby, at the price of a slower recovery.
Pilot-light	Only the core data is kept continuously replicated; the rest of the environment is built out on failover. Higher RTO. The lowest steady-state cost of the standing-infrastructure patterns.
Backup & restore	No standing standby at all — recovery is a restore from backup. Highest RTO and RPO, and the cheapest pattern for workloads where that gap is genuinely tolerable.

Read left to right, cost and readiness fall as the objective loosens. The mistake is not picking the wrong pattern in isolation — it is picking one pattern and applying it to every workload, regardless of what each one is actually worth.

The objective picks the pattern — not the reverse

A common failure mode is architectural fashion: a team adopts active-active because it is the pattern the industry talks about, then discovers the operational overhead of keeping two live sites consistent was never justified by the workload’s actual RTO. The reverse failure is just as common and quieter — a workload with a genuinely tight RTO sits on backup-and-restore because nobody set the objective explicitly, and the gap is only discovered during an incident. An RTO/RPO matrix, built per critical workload with the business owner who carries the impact, closes both failure modes at once: it makes the objective explicit before the pattern is chosen, and it stops one posture from being applied where it is not warranted.

Replication strategy follows RPO

RPO also determines how data is replicated, not just where the standby sits. A near-zero RPO generally calls for synchronous replication — every write confirmed on the standby before it is acknowledged — which adds latency and demands a resilient link between sites. A looser RPO can rely on asynchronous replication, where the standby trails the primary by seconds or minutes, or on scheduled snapshots and backups where an RPO measured in hours is acceptable. Choosing synchronous replication for a workload with a four-hour RPO adds cost and latency for no recovery benefit; choosing snapshots for a workload with a near-zero RPO leaves an exposure nobody has actually accepted. The replication method is a direct consequence of the number set earlier, not a separate decision made on its own merits.

DR runbooks: the plan that has to survive contact with an incident

A standby pattern and a replication method get you the infrastructure to recover. A DR runbook is what makes that infrastructure usable under pressure. A credible runbook is scoped to one recovery scenario for one workload: the conditions that trigger it, the exact recovery sequence, the roles involved, the validation steps that confirm the workload is genuinely back, and the fallback if a step fails. It is written to be followed by someone who did not design the system, at 3am, without the original architect on the call.

A runbook that has never been exercised is a draft, not a plan. The test strategy — what gets tested, how often, and to what evidence standard — is part of the design, not an afterthought once the documents are filed. Tabletop walkthroughs, partial failover drills and full failover tests each surface different gaps, and the right mix depends on how tight the workload’s RTO actually is: a fifteen-minute RTO deserves more than an annual tabletop.

Putting it together

The design sequence, in order: set RTO and RPO per critical workload with the people who own the business impact; choose the standby pattern the objective actually justifies, not the one that is fashionable; match the replication method to the RPO; write DR runbooks scoped to real recovery scenarios; and define how those runbooks get tested. Handled in that order, resilience spend lands where the business impact is real, and the plan a team executes during an incident has already been proven — not assumed. The architecture layer sits above day-to-day operations: this work produces the matrix, the pattern, the runbooks and the test strategy as documents your team or your MSP holds and executes.