RTO and RPO Explained: How to Set Recovery Targets
RTO (recovery time objective) is the longest a system can be down before the business is hurt. RPO (recovery point objective) is how much data, measured in time, you can afford to lose. An RTO of 2 hours and an RPO of 15 minutes means: back online within 2 hours, losing no more than 15 minutes of changes.
Key takeaways
- RTO is about downtime and looks forward from the outage. RPO is about data loss and looks back to the last good copy.
- Both are business decisions first. Set them from a business impact analysis, then pick the technology that can meet them.
- RPO drives backup and replication frequency. RTO drives how much standby infrastructure and automation you pay for.
- Tier your systems. Payment and order flows may need minutes; archives and test environments can usually wait a day.
- On AWS, the four standard strategies (backup and restore, pilot light, warm standby, multi-site) trade cost against recovery speed.
- A target you have never tested is a guess. Measure real recovery times in drills and compare them with the targets.
What is RTO (recovery time objective)?
RTO is the maximum acceptable time between a disruption and the moment a service is usable again. If your order system has a 1-hour RTO, the recovery plan, the people and the infrastructure must be able to bring it back within that hour.
NIST defines RTO as "the overall length of time an information system's components can be in the recovery phase before negatively impacting the organization's mission" (NIST glossary, from SP 800-34 Rev. 1). Note what the clock includes: detecting the incident, deciding to fail over, restoring or starting systems, and checking that they work. Teams often budget only for the technical restore and forget the first and last steps.
What is RPO (recovery point objective)?
RPO is the point in time your data must be recoverable to. NIST puts it simply: "the point in time to which data must be recovered after an outage" (NIST glossary). In practice you express it as a duration: an RPO of 4 hours means you accept losing up to 4 hours of changes.
A cash-register comparison helps. If you photograph the till roll every hour and the shop loses power, you lose at most one hour of sales records. That hour is your RPO. Banks and payment processors usually aim for seconds or near zero. An internal wiki may be fine with a day.
What is the difference between RTO and RPO?
RTO measures how long you are down; RPO measures how much data you lose. Both are expressed in time, which is why they get mixed up, but they answer different questions and are met with different tools.
| RTO | RPO | |
|---|---|---|
| Question it answers | How long can we be offline? | How much recent data can we lose? |
| Direction | Forward from the outage | Backward from the outage |
| Typical unit | Minutes to days | Seconds to hours |
| Main levers | Standby capacity, automation, runbooks, failover | Backup frequency, replication, transaction logs |
| What makes it expensive | Keeping infrastructure warm or running in a second site | Continuous or synchronous replication |
Microsoft's reliability guidance puts it the same way: RPO is the maximum duration of acceptable data loss and RTO the maximum duration of acceptable downtime, both set per workload or flow (Azure disaster recovery overview). The two targets are independent. A reporting database rebuilt from source systems can have a long RPO but still need a short RTO. A log archive can have a tight RPO and a relaxed RTO.
How do you calculate RTO and RPO?
Start from business impact, not from what your backup tool can do. The steps below follow the business impact analysis approach in NIST SP 800-34 Rev. 1, the US contingency planning guide many European teams also use as a template.
- List business processes, not servers. "Take customer orders" or "run payroll", then map the applications and data each one depends on.
- Estimate the cost of downtime per hour. Lost revenue, staff who cannot work, contractual penalties, regulatory exposure and reputation.
- Find the maximum tolerable downtime. The point where the impact becomes unacceptable. RTO must sit below it, with margin for detection and decision time.
- Estimate the cost of lost data. Can the data be re-entered or rebuilt from another system? How many transactions change per hour?
- Map dependencies. DNS, identity (Entra ID, IAM), network links, licence servers and third-party APIs often set the real recovery time.
- Price the options. Compare what it costs to hit 15 minutes, 4 hours or 24 hours for each system.
- Agree the targets with the business owner and write them down per system.
A worked example
The figures below are illustrative, to show the arithmetic. An online shop takes about €10,000 in orders per hour. Management decides that losing more than €2,500 in a single incident is unacceptable.
- RTO: €2,500 ÷ €10,000 per hour = 0.25 hours, so 15 minutes.
- RPO: a lost order is hard to recover because the customer has gone, so the target is about 1 minute.
- What that implies: replicated databases with automated failover, not nightly backups.
The same company's internal file share serves 50 people. If the business can live with a day of disruption and files change slowly, an RTO of 24 hours and an RPO of 4 hours can be met with standard backups. The difference in cost between those two systems is large. That is the reason to set targets per system instead of one number for the whole company.
How to tier systems by recovery target
Most organisations group systems into three or four tiers so every application does not need its own debate. The ranges below are common starting points, not standards. Adjust them to your own impact analysis.
| Tier | Examples | Typical RTO | Typical RPO | Usual approach |
|---|---|---|---|---|
| 1. Mission-critical | Payments, order intake, core transaction systems | Minutes | Seconds to minutes | Replication plus automated failover, warm standby or active/active |
| 2. Business-critical | ERP, CRM, email | A few hours | Minutes to an hour | Pilot light or frequent snapshots with scripted restore |
| 3. Important | Reporting, internal collaboration tools | Up to a day | Hours | Backup and restore with infrastructure as code |
| 4. Non-critical | Archives, development and test | Days | A day | Daily backups, rebuild on demand |
Which DR strategy meets which recovery target?
The tighter the target, the more you pay to keep a second environment ready. AWS describes four strategies in its disaster recovery whitepaper, from low cost and low complexity to multiple active Regions. The whitepaper's diagram places them roughly at hours, tens of minutes, minutes and near real time.
- Backup and restore. Data and infrastructure templates are copied to another Region. You rebuild after a disaster. Cheapest, slowest.
- Pilot light. Data is replicated and core components exist but are switched off. You "turn on" and scale up during recovery.
- Warm standby. A scaled-down copy runs all the time. Recovery means scaling it up and moving traffic.
- Multi-site active/active. The workload runs in two or more Regions at once. Recovery is mostly a routing change, at the highest cost.
Two practical points from the same whitepaper. First, back up configuration and code, not just data: without infrastructure as code such as CloudFormation or CDK, rebuilding in another Region takes longer and may break your RTO. Second, a single-site failure inside one Region is often covered by a well-architected Multi-AZ design plus backups. You need cross-Region strategies when your definition of disaster includes losing a whole Region, or when regulation requires it.
What sets the RPO floor on managed databases
Check what the platform can deliver before you promise a number. Amazon RDS, for example, uploads transaction logs to S3 every five minutes, so point-in-time restore from those logs cannot guarantee less than that window (AWS RDS documentation). If you need a tighter RPO, add a standby replica or a cross-Region replica and test it.
Common reasons recovery targets are missed
- Hidden dependencies. The application restores in 20 minutes, but DNS, identity or a licence server takes two hours.
- Component tests only. Database restores work, yet nobody has tested the full chain from failover to a working checkout.
- Stale runbooks. Procedures written before the last migration point to servers that no longer exist.
- Supplier mismatch. Your RTO is 1 hour, but the SaaS or hosting contract promises a 4-hour response.
- Backups that share the blast radius. Copies in the same account or Region as production can be deleted or encrypted in the same ransomware incident.
How to test and govern RTO and RPO
Treat the targets as controls you can audit. A cadence many teams use:
- Quarterly tabletop walk-through of the recovery runbooks.
- Restore tests of individual components (a database, a server, a bucket) at least twice a year.
- A full failover drill for tier 1 systems once a year, with the clock running.
- A record of actual recovery time and data loss from each test, next to the target.
- A named owner per system and a change process that revisits targets after major releases or migrations.
Evidence from these tests also answers auditors. NIS2 and DORA both expect documented business continuity and backup management, and a test log is the simplest proof.
Example: near-zero downtime during a database move
When Opsio moved WorkBuster's SaaS recruitment platform to AWS, a near-zero downtime approach was a hard requirement because the platform is used around the world. The MySQL data held in a VMware environment was migrated with as little disruption as possible onto a Multi-AZ MySQL RDS setup, with the infrastructure defined in CloudFormation templates. Multi-AZ databases and infrastructure as code are the same building blocks that shorten RTO and tighten RPO in a disaster recovery design.
How Opsio helps
Opsio runs backup and disaster recovery as part of its cloud disaster recovery service and AWS managed services, against defined RPO/RTO targets with quarterly restoration drills. We start by agreeing targets per system with the business owner, map each tier to a strategy, keep backups outside the production blast radius and record the result of every drill. For a shorter definition of the two terms, see our knowledge base answer what RPO and RTO mean in disaster recovery.
Frequently asked questions
What is a good RTO and RPO?
There is no single good value. For revenue-generating systems, targets of minutes for RTO and near zero to a few minutes for RPO are common. For internal tools, hours to a day is usually acceptable. A good target is one the business agreed to and you have proven in a test.
Is RTO always longer than RPO?
No. They are independent. A system rebuilt from other sources can tolerate a long RPO but still need a short RTO, and the reverse also happens. In practice, tier 1 systems often have both short.
What does an RPO of zero mean?
No committed data may be lost. That requires synchronous replication to a second location, which adds cost and write latency. Most teams reserve it for payments and ledgers.
How are RTO and MTD different?
Maximum tolerable downtime (MTD) is the longest the business can survive without the process. RTO is the target for restoring the system and must be shorter than MTD, leaving time to verify data and resume work.
How often should recovery targets be reviewed?
At least once a year, and after any migration, major release or change in how the business depends on a system. Re-test after each change.
For hands-on delivery in India, see disaster recovery service provider India.
Related reading
About the Author
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.