RPO and RTO turn “we need the database back quickly” into measurable requirements. They should be agreed with the business before choosing backup frequency, replication, storage, or failover automation.
1. The Two Objectives
Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time before the incident. If the RPO is 15 minutes, the recovery process must normally restore the database to a point no more than 15 minutes old.
Recovery Time Objective (RTO) is the maximum acceptable time to restore the service after disruption. It includes detection, decision-making, infrastructure provisioning, database recovery, validation, and application reconnection.
RPO limits data loss. RTO limits service downtime.
2. A Practical Database Scenario
Consider an order database with these approved requirements:
- RPO: 15 minutes.
- RTO: 60 minutes.
- Retention: 30 daily recovery points and 12 monthly backups.
- Recovery must survive loss of the primary server and its storage.
A nightly dump alone fails the RPO because it could lose almost 24 hours of transactions. A large dump that takes two hours to restore also fails the RTO, even if it contains the required data.
A more suitable design could combine:
- A standby database for common host failures.
- Physical base backups on a defined schedule.
- Continuous PostgreSQL WAL archiving or MySQL binary log retention.
- An encrypted backup copy in an independent account or location.
- A documented and regularly timed recovery procedure.
3. RPO Determines Data Protection
The RPO determines how frequently recoverable changes must leave the primary failure domain:
- 24-hour RPO: a verified daily backup may be sufficient.
- 1-hour RPO: hourly snapshots or log shipping may be required.
- 15-minute RPO: continuous transaction-log archiving with monitoring is usually more practical.
- Near-zero RPO: synchronous replication may be needed, with additional latency and availability trade-offs.
Replication alone is not enough. Logical errors and malicious changes can reach replicas, so point-in-time recovery and protected backups are still necessary.
4. RTO Determines Recovery Architecture
RTO includes more than database restore speed. Measure the complete sequence:
- Detect and classify the incident.
- Select a safe recovery point.
- Provision or activate the target system.
- Restore the base backup and replay transaction logs.
- Validate database consistency and application behavior.
- Switch traffic and monitor the recovered service.
If infrastructure provisioning consumes 40 minutes of a 60-minute RTO, the database team has only 20 minutes left. Prebuilt standby systems, infrastructure as code, automated restore steps, and rehearsed decisions can reduce that delay.
5. Define Different Service Tiers
Not every database needs the same target. A practical catalog might use:
- Tier 1: revenue or customer-facing databases — low RPO and RTO.
- Tier 2: important internal systems — moderate RPO and RTO.
- Tier 3: development, reporting, or rebuildable data — longer objectives.
Lower objectives cost more. They may require additional replicas, storage, network capacity, licenses, automation, and on-call coverage. The service owner should approve that trade-off rather than leaving it to the DBA alone.
6. Prove the Objectives
During each recovery test, record:
- Incident start, detection time, and recovery completion time.
- Timestamp of the last recovered transaction.
- Backup and log files used.
- Validation queries and application checks.
- Failed, undocumented, or unexpectedly manual steps.
Calculate the achieved recovery point and recovery time from that evidence. A design meets its objectives only when repeated tests demonstrate it under realistic conditions.
Start with business impact, establish measurable RPO and RTO values, and then design the database platform around them. Tools are implementation details; recoverability is the outcome.