RTO and RPO in Disaster Recovery: Definitions, Examples and How to Set Them

RTO (recovery time objective) is the longest a system may stay down after a disruption. RPO (recovery point objective) is the most data you can afford to lose, measured as time since the last usable copy. An RTO of 4 hours and an RPO of 15 minutes means: back online within 4 hours, losing at most 15 minutes of data.

Key takeaways

• RTO looks forward from the outage (how long until service is back). RPO looks backward (how old is the last good copy of the data).
• Both are business decisions. Set them per system through a business impact analysis, then pick technology that meets them.
• Backup frequency caps your RPO: with backups every 4 hours, worst-case data loss is about 4 hours.
• Lower targets cost more. Near-zero RTO/RPO needs replication and standby capacity in a second location.
• Targets on paper mean little until a test has measured the actual recovery time and data loss.

What is RTO in disaster recovery?

RTO is the maximum acceptable time between a service going down and coming back. AWS defines it as "the maximum acceptable delay between the interruption of service and restoration of service" in its whitepaper Disaster Recovery of Workloads on AWS. NIST frames it from the business side: the time a system can be in recovery "before negatively impacting the organization's mission or mission/business processes."

RTO covers the whole recovery, not just the technical restore. Detection, the decision to invoke the DR plan, restoring data, validating the application and switching users over all count against it. Teams that only time the restore usually miss their RTO in a real event.

What is RPO in disaster recovery?

RPO is the maximum acceptable data loss, expressed in time. AWS calls it "the maximum acceptable amount of time since the last data recovery point." If your RPO is 1 hour, then after a failure you must be able to restore data that is no more than 1 hour old.

RPO is driven by how often you copy data. Nightly backups give a worst-case RPO of around 24 hours. Database log backups every 15 minutes give roughly 15 minutes. Continuous replication can bring it close to zero, with one caveat covered below: replication copies corruption and deletions too.

RTO vs RPO: the difference at a glance

Worked examples

Example 1: an order system. A web shop sets an RTO of 4 hours and an RPO of 15 minutes. The database fails at 10:00. The shop must take orders again by 14:00, and at most the orders placed between 09:45 and 10:00 can be missing. Nightly backups cannot meet this; the shop needs transaction log backups or replication at least every 15 minutes, plus a scripted way to rebuild the application tier inside 4 hours.

Example 2: checking a backup schedule. A finance system is backed up every 6 hours and a full restore takes 3 hours. If the business asks for an RPO of 1 hour and an RTO of 2 hours, both targets fail: worst-case data loss is about 6 hours and the restore alone exceeds the RTO. The fix is either more frequent backups plus a faster recovery method, or a business decision to accept looser targets.

Example 3: tiering a portfolio. Most companies group systems into tiers instead of setting targets one by one. The figures below are illustrative, not a standard.

The strategy column follows the four approaches in the AWS whitepaper, where backup and restore delivers recovery in hours and multi-site active/active in near real time. Our guide to the disaster recovery plan explains each strategy and how to choose.

How do RTO and RPO relate to maximum tolerable downtime?

Maximum tolerable downtime (MTD) is how long a business process can be disrupted before the damage becomes serious. NIST SP 800-34 explains that the RTO "must normally be shorter than the MTD", because once systems are back, staff still need time to catch up on backlog and re-enter lost data. RPO is not part of MTD. It describes how much data the process can afford to lose (NIST SP 800-34 Rev. 1).

In practice: if the order process can survive 8 hours without systems, and catching up takes 2 hours, the IT RTO must be 6 hours or less.

How to set RTO and RPO

1. List business processes and their dependencies. Map each process to the applications, databases, identity services and third parties it needs.
2. Estimate the impact of downtime and data loss over time. Revenue, contractual penalties, regulatory exposure, safety and reputation. AWS points out that impact can depend on timing: a payroll outage just before pay day matters far more than one just after.
3. Propose targets per tier and let the business owner sign them off. IT should not pick them alone.
4. Price the options. AWS advises that if the recovery strategy costs more than the failure it protects against, it "should not be put in place unless there is a secondary driver such as regulatory requirements."
5. Design and test. Build the backup, replication and failover mechanisms, then run a test and record the achieved recovery time and recovery point.
6. Review yearly and after major changes. Systems drift between tiers as the business changes.

Which technologies meet which targets?

• Scheduled backups and snapshots suit RPOs of hours. They protect well against corruption and deletion because each copy is a fixed point in time.
• Point-in-time recovery (database log backups) brings the RPO down to minutes for databases.
• Asynchronous replication to another region gives an RPO of seconds to minutes, depending on replication lag.
• Synchronous replication across Availability Zones gives an RPO close to zero, at the cost of write latency. Microsoft's Azure Well-Architected guidance on disaster recovery suggests synchronous replication across zones for high-priority data and asynchronous replication across regions for lower-priority data.
• Standby environments and automation (pilot light, warm standby, infrastructure as code, scripted DNS failover) reduce the RTO.

Watch the replication trap. AWS notes that continuous replication "may not protect against disaster events such as data corruption or malicious attack" as well as point-in-time backups do. A ransomware-encrypted database replicates as quickly as a healthy one, so keep point-in-time copies alongside replicas.

How to prove you meet your targets

Measure, do not assume. During each DR test, note when the outage started, when the plan was invoked, when service returned and the timestamp of the last recovered transaction. Those give your achieved RTO and RPO. Microsoft's guidance recommends a mix of tabletop exercises, dry runs in non-production and production-level drills. Track the results over time and fix the slowest step first.

How Opsio helps

Opsio runs business impact workshops, sets RTO/RPO per tier with your business owners, and builds and tests the matching recovery design on AWS and Azure through its cloud disaster recovery service. For the SaaS recruitment platform WorkBuster, a near-zero downtime approach was a hard requirement when Opsio moved the platform to AWS. The design uses a multi-AZ, highly available MySQL database on Amazon RDS, with the infrastructure defined in CloudFormation templates.

Frequently asked questions

What is the difference between RTO and RPO?

RTO is how long a system may be unavailable after a disruption. RPO is how much data, measured in time, you can afford to lose. RTO is about downtime; RPO is about data loss.

What is a good RTO and RPO?

There is no universal number. A payment system might need minutes for both, while an internal reporting tool can accept 24 hours. Derive targets from the cost of downtime and data loss for each business process, then check the cost of meeting them.

Can RPO be zero?

Close to zero, yes, with synchronous replication or multi-site active/active designs. True zero data loss is hard to guarantee across regions because of distance and latency, and replication alone does not protect against corruption.

Is RTO the same as an SLA?

No. An SLA is a promise to customers about availability or response. RTO is an internal recovery target for a disaster scenario. Your RTO should support your SLAs, but they are measured differently.

How often should recovery targets be reviewed?

At least once a year and after major changes to systems, suppliers or the business. Re-measure them in every DR test, since the achieved values are what count.