Skip to main content
RunBook Academy

← All checklists in Backup & DR

Annualbdr-rpo-rto-review

RPO and RTO review

21 items ·15 critical ·6 warn ·0 info

How to use

Annually, and with the service owner present for the last few items. The review compares two things: the objectives the estate publishes, and the evidence each one was derived from. A schedule read out of a configuration file tells you how often a copy is taken. It does not tell you what the recovery point is, and it tells you nothing whatever about the recovery time.

Work service by service, and inside each service, failure model by failure model. One system protected by hourly snapshots and a nightly offsite repository has at least two recovery points and usually two recovery times, and an answer that holds for one of them is not evidence for the other. An item that fails for any failure model in scope fails.

Where the numbers come from

The worst-case recovery point is the interval between copies plus the duration of the copy itself, evaluated at the instant before the next one would have run. The mean is not the answer, because nobody gets an average outage, and the last incident is not the answer either, because it describes one arrival time.

For deletion and corruption the binding constraint is retention held against detection latency rather than the interval. Where nothing that survives predates the mistake, there is no recovery point to publish for that failure model, and the review says so in those words.

Continuous mechanisms are the ones that fail quietly, so their published number rests on observed lag: the lag has to be measured and alerted on, or the recovery point becomes the age of the last copy that actually landed.

The recovery time is a sum over stages with observable boundaries, and one row usually dominates it. An archive tier contributes a documented wait before the first byte becomes available, which no link upgrade shortens. The sum comes from a drill with a date on it, never from the backup window:

Read-only / Safethe incremental backup number is not the restore number
$ a second backup of the unchanged dataset, beside the first backup and the restore
--- the asymmetry that IS large, and is the point of the exercise ---
a second backup of 'big' with nothing changed:
backup  : .73s

first backup of 400 MiB : 1.49s
second backup, unchanged: .73s
restore of 400 MiB      : 1.07s

Those seconds belong to that machine on that date and must not be carried anywhere. The shape is what transfers: the nightly job reports the middle number and an incident needs the last one, because backup stores only what changed while a restore writes the whole recovery point.

Access this needs

Read access to the schedule and retention configuration of every mechanism in scope, to the monitoring that watches any continuous path, to the drill records, and to the objectives document itself. Read access, too, to wherever the record of the business agreement lives.

Nothing here requires write access to a repository, a snapshot or a bucket. A reviewer who needs it to complete an item has found a defect in that repository’s permissions.

The final items need a person rather than an account: somebody who can speak for the business about tolerable loss and tolerable downtime.

What the review produces

One row per service and failure model, carrying the published recovery point and recovery time, the numbers this review derived, the architecture and assumptions behind each, the date of the measurement they rest on, the dominant stage of the recovery, and the gap.

The gap is the output. It goes to the service owner whether or not it is comfortable reading, because it is the only honest input to the decision that follows: fund a change to the architecture, tier the promise, or accept the risk in writing with a name and a date against it. Numbers that were derived, agreed and recorded survive an incident review afterwards. Numbers that were wished do not.

Sign-off

  • Reviewer: ____ Date: ____
  • Service owner: ____ Date: ____
  • Backup platform owner: ____ Date: ____

Every critical item must pass. A failing critical item means a published objective is not derived from anything, which is a blocker rather than a note for later: record the disposition of every item that did not pass, and the name of whoever accepted the residual risk.

Critical15 items

  1. ls -1t /var/log/rbdr-drill/ | head -5
  2. cut -f1,2 /var/log/rbdr-drill/latest.tsv
  3. grep -rn "assumptions" /srv/rbdr-objectives/
  4. grep -rn "agreed-by\|agreed-on" /srv/rbdr-objectives/

Warning6 items