A recovery point objective (RPO) is the maximum amount of recent data a business is prepared to lose when it recovers a system, expressed as a span of time before the disruption. An RPO of 15 minutes means that after recovery, at most the last 15 minutes of changes should be missing; an RPO of 24 hours accepts losing up to a day. The RPO decides how often data must be copied, and that choice drives much of the cost of a backup or recovery design.
At a glance
- RPO measures tolerable data loss, counted backward in time from the moment of disruption.
- It is set per system or process, ideally from a business impact analysis.
- Backup frequency and replication method determine the RPO you can actually achieve.
- Shorter RPOs cost more in storage, bandwidth and tooling.
- RPO is paired with recovery time objective (RTO), which measures tolerable downtime.
What problem it solves
Every recovery brings data back from a copy, and every copy is older than the moment things went wrong. The question is how much older is acceptable. For an email archive, losing a day may be a nuisance. For an order system, a day of lost transactions can mean unfilled orders, billing errors and customer disputes.
Without an agreed RPO, backup schedules tend to be set by habit, often nightly for everything. That leaves busy systems underprotected and quiet ones copied more than they need. An RPO makes the trade-off explicit, so the business decides how much loss it can live with and IT designs and prices protection to match.
How it works
Start from business impact. A business impact analysis (BIA) asks what each process would lose if recent data disappeared, and how hard that data would be to recreate. That sets the RPO for the systems behind each process.
Match the copy method to the target.
- Scheduled backups (nightly, or several times a day) suit RPOs measured in hours or a day.
- Frequent snapshots or log backups, common for databases, can bring the RPO down to minutes.
- Asynchronous replication copies changes continuously with a short lag, often giving RPOs of seconds to minutes.
- Synchronous replication writes every change to two places before confirming it, aiming for near-zero data loss, but usually only works over limited distances and adds cost.
Keep enough history. The newest copy is not always a usable one. Corruption, accidental deletion and ransomware can all be copied into recent backups or replicas, so recovery may need a point from hours or days earlier. Retention, and protection such as immutable backup, determine how far back you can go.
Monitor and test. Job monitoring and restore testing show whether the RPO can actually be met. If jobs fail, systems are skipped or the newest recovery point won’t restore, you may have to recover from an older point, and the data you actually lose can exceed the RPO.
When it matters for buyers
- When choosing a backup or DRaaS service. Providers’ copy frequency, replication options and retention decide which RPOs they can meet, and at what price.
- When data changes fast. Transaction, order, clinical or financial systems usually need shorter RPOs than file shares or archives.
- When planning for ransomware. The real question becomes how recent a clean copy you can find, not just how recent a copy you have.
- When insurers or customers ask. Documented RPOs, with evidence that backups run and restore, are a common requirement.
- When moving to SaaS. Built-in retention features in SaaS applications may not meet the RPO you would set for that data.
Questions to ask vendors
- What copy frequencies and replication options do you support for each type of system we run?
- How often do your customers’ recoveries meet their RPO in tests, and how do you report missed or failed jobs?
- How many recovery points do you keep, for how long, and what does longer retention cost?
- Are recovery points protected against deletion or change by a compromised admin account?
- How do you help us find a clean recovery point after ransomware or corruption?
- Does tighter replication need extra bandwidth or licensing on our side?
How it differs from RTO
Recovery time objective (RTO) and RPO are set together but answer different questions. RTO asks how long you can be down; RPO asks how much data you can lose. They don’t move together: a database replicated every minute has a short RPO, but if starting it at another site takes a day, its RTO is a day. A system restored in an hour from last night’s backup has a short RTO but an RPO of up to a day. Backup as a service (BaaS) is usually chosen to meet RPO and retention needs, while disaster recovery as a service (DRaaS) is usually chosen to meet tight RTOs as well; both fit inside a wider business continuity and disaster recovery (BCDR) plan. Our backup as a service overview covers how providers handle copy frequency and retention.