RPO, or recovery point objective, is the maximum acceptable amount of data loss after an incident, expressed as a span of time before the failure. In server reliability, an RPO of 15 minutes means that after an outage the service may be restored to a state no older than 15 minutes before the failure, so at most 15 minutes of writes may be lost.
RPO is a business target, not a technical setting. It is agreed with the owners of a service and then fulfilled by technical means such as backup frequency, log shipping and replication. It always appears together with RTO, the recovery time objective, which limits how long the restoration itself may take.
What RPO measures
RPO measures the distance between the last recoverable copy of data and the moment of failure. Every write made after the last copy that survives the incident is lost, so the gap between consistent copies sets the worst-case loss window.
For example, nightly backups taken at 01:00 give an effective RPO of up to 24 hours: a disk failure at 23:30 loses almost a full day of changes. Adding transaction log backups every 10 minutes reduces the worst case to about 10 minutes plus the time needed to copy the log off the server.
Two numbers should be kept apart. The target RPO is what the business requires, while the achieved RPO is what the current design actually delivers under realistic failure conditions. Only regular testing shows whether the two match.
Technologies and the RPO they can achieve
Each data protection method has a natural RPO range determined by how often it captures changes and whether the copy leaves the failing system. The ranges below are typical values and depend on configuration, network bandwidth and write volume.
| Method | Typical RPO | What determines it | Cost and complexity |
|---|---|---|---|
| Daily full or incremental backup | Up to 24 h | Backup schedule | Low |
| Hourly snapshots | Up to 1 h | Snapshot interval and off-site copy | Low to moderate |
| Transaction log shipping | 1 to 15 min | Log backup and transfer interval | Moderate |
| Asynchronous replication | Seconds to minutes | Replication lag under load | Moderate to high |
| Synchronous replication | Near zero | Commit waits for the remote copy | High, adds write latency |
Synchronous replication confirms a write only after a second copy has stored it, which gives an RPO close to zero. The price is added latency on every write and a practical distance limit, commonly tens of kilometers, beyond which the round trip slows the application noticeably.
Asynchronous replication does not wait, so the replica trails the primary by a replication lag. That lag is the real RPO at the moment of failure, and it grows during write bursts or network congestion, exactly when failures are more likely.
RPO compared with RTO and other reliability metrics
RPO is one of several metrics in reliability planning, and each answers a different question about an outage. Confusing them leads to designs that restore quickly but lose too much data, or keep every write but take too long to return.
| Metric | Question it answers | Unit | Main lever |
|---|---|---|---|
| RPO | How much data may be lost | Time before failure | Backup and replication frequency |
| RTO | How long recovery may take | Time after failure | Automation, failover, restore speed |
| Uptime or availability | How often the service works | Percentage over a period | Redundancy and high availability |
| MTTR | How long repairs take on average | Time per incident | Monitoring and runbooks |
High availability and failover mostly improve RTO and uptime. They protect RPO only when the standby holds a current copy of the data. Redundancy of hardware does not help at all against logical errors: a deleted table is replicated to every mirror within milliseconds, so recovery then depends on backups and their RPO.
Setting an RPO for a service
An RPO is set by asking what lost data would cost and then comparing that cost with the price of protection. A business impact analysis typically ranks services and assigns them to RPO tiers rather than calculating a unique value for each one.
| Service type | Suggested RPO | Matching design | Reason |
|---|---|---|---|
| Payment or order database | 0 to 1 min | Synchronous or low-lag replication plus logs | Lost orders mean lost revenue |
| Content management system | 15 min to 1 h | Log shipping or frequent snapshots | Edits can be redone at moderate cost |
| Internal wiki or intranet | 4 to 24 h | Daily backups with snapshots | Changes are few and recoverable |
| Test and staging servers | 24 h or more | Weekly backups or rebuild from code | Data is reproducible |
The chosen value must cover all components of a service, not only the main database. Uploaded files, message queues, search indexes and configuration all hold state, and the effective RPO is that of the weakest component if they cannot be restored to a consistent point together.
Common mistakes with recovery point objectives
The most frequent error is to assume that the backup schedule equals the RPO. A backup that runs every hour but takes 40 minutes to complete, or one that stays on the same server until a nightly transfer, has a far worse effective RPO.
- Untested backups give an unknown RPO, because a corrupt or incomplete copy cannot be restored.
- Replication without point-in-time recovery fails against ransomware and accidental deletion.
- Ignoring replication lag hides an RPO of minutes behind a nominal value of seconds.
- Copies on the same storage share the same failure and provide no real recovery point.
- Inconsistent component restores combine a database from one moment with files from another.
A sound practice is to monitor the age of the latest restorable copy continuously and alert when it exceeds the target. Periodic restoration tests then confirm that the recorded recovery point can actually be brought back into service.
Put simply
Imagine writing a long document and saving it every ten minutes. If the computer suddenly crashes, the most work that could be lost is ten minutes. That ten-minute limit is the recovery point objective.
Companies decide in advance how much recent work they can afford to lose for each system. Important systems get short limits and more frequent copies, while less critical ones can be saved less often at lower cost.
In practice
A regional online retailer runs its order database on a single server with nightly backups at 02:00. A review of reliability risks shows that a failure late in the evening could erase a full day of orders, which management considers unacceptable. The agreed target becomes an RPO of 5 minutes for orders.
The operations team adds continuous transaction log archiving to object storage in another data center, with each log segment closed and shipped at least every 60 seconds, and keeps the nightly full backup as the base. An alert fires whenever the newest archived log is more than 3 minutes old.
Months later, a storage controller fails during evening peak traffic. The team restores the last full backup and replays the archived logs, recovering the database to a point about 70 seconds before the failure. Customers whose orders fell into that short window are contacted individually, and the target is shown to hold in a real incident.