RPO and RTO often appear in a table next to the word “backup”. That is not yet a recovery plan. Start by stating what must return: a database, an API or the user's ability to finish a task.

Two different measures

RPO (Recovery Point Objective) is the maximum acceptable data loss expressed as time: how old the last valid recovered state may be. RTO (Recovery Time Objective) is the maximum elapsed time to restore the agreed function after service interruption. Define when the clock starts, which function counts and who accepts the result. RPO is not a backup schedule; RTO is not a machine boot time.

Fictional example. A portal targets an RPO of five minutes and an RTO of 30 minutes. An outage is detected at 10:00. Its last valid restored write is from 09:52, and users can again submit and retrieve an application at 10:42. The achieved values are at least eight minutes of lost writes and 42 minutes of downtime. Both targets are missed even if a database backup job ran at 09:55.

Why multiple stores change the calculation

Metadata in a database, attachments in object storage and messages in a queue do not automatically form one recoverable transaction. You may retrieve a row without its file or replay a message already processed. Define a business identifier for reconciliation, a way to detect missing items and a policy for duplicates. If a technically consistent point is unavailable, describe compensation and how losses are approved.

A useful recovery drill

  1. Select the critical user journey and all of its dependencies. Distinguish full service from a limited mode.
  2. In an isolated environment simulate loss of the primary region. Check that backups, keys and instructions remain accessible without it.
  3. Restore a representative volume of data and services; time the interval from detection to a successful user journey, rather than until “the server responds”.
  4. Reconcile records, files and messages. Count the latest available write, missing objects, duplicates and work requiring manual completion.
  5. Compare the results with the objectives. Assign an owner and deadline to every gap; repeat after material architecture changes.

Choosing more frequent replication, backups, active redundancy or a manual workaround depends on the cost of lost data and downtime. Each option carries different cost and risk; none removes the need to rehearse. Replication can faithfully copy a bad write too.

Question for your project: when did you last restore the complete user journey, and what RPO and RTO did you measure rather than declare?