RPO and RTO

What RPO and RTO mean and what they drive

Both terms come from contingency planning. NIST SP 800-34 Rev. 1 defines the recovery point objective as the point in time to which data must be recovered after an outage, a measure of how much data loss the business process can tolerate. The recovery time objective is the maximum time a system resource can stay unavailable before the impact becomes unacceptable. NIST adds a third figure, maximum tolerable downtime (MTD), and says the RTO must normally be shorter than the MTD.

Each drives a design choice. RPO sets how often you back up or replicate: a nightly backup means losing up to about a day of changes. RTO sets how you recover. NIST's example table pairs low-impact systems with simple backups and a cold site, and high-impact ones with mirrored systems and a hot site. The AWS disaster recovery options run from backup and restore through pilot light and warm standby to multi-site active/active, with rising cost and complexity.

Measuring RPO and RTO in a restore test

The targets are decisions; a restore test tells you what you actually achieve. Restore onto a clean directory or a scratch server and time it. With restic (see the backup strategy guide):

# RPO: how old is the newest backup right now?
date -u
restic snapshots --json | jq -r 'max_by(.time).time'

# RTO: how long does the restore itself take?
time restic restore latest --target /srv/restore-test

Per the restic scripting docs, time is when the backup started, so later changes are not covered. The gap to now is your worst-case loss.

Time the whole recovery, not just the copy. Illustrative example, invented numbers: the last backup started at 02:00 and the server fails at 01:30 the next day, so 23.5 hours of data are lost against a 4 hour RPO target: fail. Provisioning 25 minutes, restore 40, configuration 30 and checks 15 is 1 hour 50 minutes against a 4 hour RTO target: pass.

Limits and common mistakes

• A green backup job is not an RTO. Only a timed restore, including provisioning, DNS and application checks, shows how long recovery really takes.
• Zero is not on offer. AWS notes that even with best practices recovery time and recovery point will be greater than zero, and for corruption or deletion the recovery point is before the problem was discovered.
• Replication is not backup. A mirror copies a deletion or encryption within moments. Keep point-in-time copies, ideally one that cannot be deleted from the server, as the 3-2-1 rule extensions suggest.
• One number for everything. A database and a folder of static files rarely need the same objectives, so set them per service.
• Forgotten dependencies. DNS records, certificates, secrets and the backup passphrase are all part of recovery time.
• Targets without budget. Tighter objectives need more storage, standby capacity and effort, so write down what you chose to pay for.

Fitting RPO and RTO into a recovery routine

Write the targets per service in a short runbook. Set the backup schedule from the RPO with margin, and alert on a missed run, because one failed night silently doubles your real RPO. Pick the restore method from the RTO: a scripted rebuild plus restore for hours, a warm standby for minutes.

Repeat the restore test on a calendar, for example quarterly and after big infrastructure changes, and record measured against target. CISA's #StopRansomware Guide likewise advises offline, encrypted backups and regular testing of their availability and integrity. The measured RTO also tells you what to promise during an incident, and after a restore you still have to prove the data and services are right, as described under recovered versus verified.

The full plan, with tools and retention, is in the VPS backup strategy guide, and the incident side is in the ransomware protection guide.

Related terms: Backup rule (3-2-1), Ransomware, Recovered vs verified, Incident response, Object Lock.