Setting RPO and RTO before designing anything

Why this matters in production

A backup design without stated targets cannot be evaluated, so it is evaluated after the incident, against targets invented at that moment.

Definitions

RPO — Recovery Point Objective
  How much data loss is acceptable.
  Determined by backup frequency.

RTO — Recovery Time Objective
  How long recovery may take.
  Determined by restore mechanics and data volume.

They are independent. A daily backup restored in ten minutes has a
24-hour RPO and a 10-minute RTO.

Deriving them from impact

Ask the application owner:
  if we lose the last N of changes, what happens?
  if this is unavailable for N hours, what happens?
Then find where the answer changes materially.

The last row matters: some data has no RPO because it is reproducible.
Identifying it removes cost from the design.

Designing to meet them

# RPO drives frequency — substitute your own pool and image:
POOL=rbd-vms
IMAGE=vm-disk-01

rbd snap create "$POOL/$IMAGE@$(date +%Y%m%d-%H%M)"   # hourly → 1h RPO

# RBD mirroring gives a much lower RPO
POOL=rbd-vms
IMAGE=vm-disk-01
rbd mirror image enable ${POOL}/${IMAGE} snapshot
rbd mirror snapshot schedule add --pool ${POOL} --image ${IMAGE} 15m
rbd mirror image status ${POOL}/${IMAGE}

# RTO drives the restore path
POOL=rbd-vms

rbd import /backups/image01.raw "$POOL"/image01-restored

An RTO shorter than the time to move the data means the data must
already be where it is needed.

Measuring

# actual RPO: the age of the newest usable copy
POOL=rbd-vms
IMAGE=vm-disk-01

rbd snap ls "$POOL/$IMAGE" --format json | python3 -c '
import sys,json
s = json.load(sys.stdin)
print("snapshots:", len(s), " newest:", s[-1]["name"] if s else "none")'

# actual RTO: measured, not estimated
POOL=rbd-vms

time rbd import /backups/image01.raw "$POOL"/rto-test
rbd rm "$POOL"/rto-test

An unmeasured RTO is a guess, and it is always optimistic. Measuring it
once per year against a representative dataset is what makes it a
commitment.

Quiz

Production discipline

State RPO and RTO before designing, and measure RTO by rehearsing the whole sequence rather than estimating the transfer — the transfer is frequently the smaller half. Where the RTO is shorter than the transfer time, the design must place the data in advance rather than move it.

Cross-course references

• Kubernetes: recovery objectives drive whether you restore or fail over
• Linux: an unrehearsed recovery time is an estimate, not a commitment