RTO vs RPO: Recovery Objectives Explained, With Targets per System
RTO is how long you can be down; RPO is how much data you can lose. Learn how to set both per system and match them to the right backup and disaster recovery method.
RTO (recovery time objective) is how long a system can be down before the outage causes unacceptable harm. RPO (recovery point objective) is how much data, measured in time, you can afford to lose. RTO drives how fast you must restore; RPO drives how often you back up or replicate. Set both per system, not once for the whole company.
Photo: Unsplash
On this page
Every backup plan eventually faces 2 blunt questions. If this system goes down right now, how long can the business wait before it comes back? And when it does come back, how much recent work can we afford to lose?
Those are your RTO and RPO. They sound like jargon, but they are the most useful numbers in disaster recovery because they turn “we need good backups” into specific targets you can design, price and test. This guide explains the difference, shows how to set targets per system and matches each target to a backup method that can actually meet it.
RTO vs RPO in one minute
Recovery time objective (RTO) is about downtime. NIST defines it as the overall length of time a system’s components can be in the recovery phase before negatively affecting the organization’s mission or business processes. In plain terms: the longest outage you can accept.
Recovery point objective (RPO) is about data loss. NIST defines it as the point in time to which data must be recovered after an outage. In plain terms: how old your restored data can be. An RPO of 1 hour means you can lose up to 1 hour of changes.
| RTO | RPO | |
|---|---|---|
| Question it answers | How long can we be down? | How much data can we lose? |
| Measured as | Time from outage to restored service | Time between the last good copy and the outage |
| Looks | Forward from the incident | Backward from the incident |
| Driven mostly by | Restore speed, standby systems, runbooks, people | Backup frequency, replication, snapshots |
| Example target | Restore the online store within 4 hours | Lose no more than 15 minutes of orders |
| Cost rises when | You need standby infrastructure ready to run | You need continuous replication |
A simple timeline helps. Imagine your last backup ran at 1:00 a.m. and the server fails at 9:00 a.m. Your actual recovery point is 8 hours of lost data. If it takes until 1:00 p.m. to restore service, your actual recovery time is 4 hours. Your RPO and RTO are the targets those actual numbers must stay within.
Where maximum tolerable downtime fits
A third term often appears in business continuity plans: maximum tolerable downtime (MTD). NIST describes it as the amount of time a business process can be disrupted without causing significant harm. MTD is the business limit; RTO is the technical target for one system, and it should be shorter than the MTD of the process that depends on it, so there is time to verify data and resume work.
Why the 2 numbers are different decisions
Teams often set one target, such as “4 hours,” and assume it covers both. It does not.
- A payroll system might tolerate a 2-day outage (long RTO) if payday is not close, but losing a day of timesheet edits would be painful (short RPO).
- A marketing website may need to be back quickly for brand reasons (short RTO), but its content changes rarely, so a daily backup is fine (long RPO).
- A payment or order system usually needs both short.
Separating the 2 lets you spend money where it matters. Short RPO costs you in backup frequency, replication and storage. Short RTO costs you in standby infrastructure, automation and practiced runbooks.
Key takeaway: RTO is about speed of recovery, RPO is about freshness of data. Set them separately for each system, because the cheapest plan that meets both is usually different for every system.
How to set RTO and RPO per system
You do not need a consultant to start. You need the people who run each business process in a room for a couple of hours.
Step 1: List your systems and the processes they support
Include SaaS tools, not only servers. Your CRM, accounting software, email, file storage, ecommerce platform and line-of-business apps all count. Note which business process each one supports and who owns it.
Step 2: Ask what an outage costs over time
For each process, ask the owner what happens after 1 hour, 4 hours, 1 day and 1 week of downtime. Think about lost revenue, missed legal or contract deadlines, safety, customer trust and staff who cannot work. The point where the answer becomes “serious harm” is roughly your MTD.
Step 3: Ask how much rework is acceptable
Ask: “If we had to restore from a copy that is 15 minutes, 4 hours or 24 hours old, could your team recreate the missing work?” Orders, payments and medical or legal records usually cannot be recreated reliably. Draft documents and analytics usually can.
Step 4: Group systems into tiers
Most organizations find 3 or 4 tiers are enough.
| Tier | Typical systems | Example RTO | Example RPO |
|---|---|---|---|
| Tier 0: Critical | Payments, order processing, core customer app | Minutes to 1 hour | Near zero to 15 minutes |
| Tier 1: Important | CRM, email, file shares, ERP | 4 to 8 hours | 1 to 4 hours |
| Tier 2: Standard | Internal tools, reporting, intranet | 1 to 2 days | 24 hours |
| Tier 3: Low | Archives, test environments | Several days or more | 24 hours to 1 week |
These are illustrative starting points, not standards. Your own numbers come from Steps 2 and 3.
Step 5: Check dependencies
A system cannot recover faster than what it depends on. If your order app has a 1-hour RTO but relies on an identity provider or database with a 1-day RTO, the real RTO is 1 day. Map dependencies and align tiers.
Step 6: Get sign-off on the cost
Present the tiers with an estimated cost to meet them. Business owners often relax targets once they see the price of near-zero recovery, and that is a healthy conversation to have before an outage, not during one.
Matching recovery targets to backup methods
Once you have targets, pick a method that can meet them. AWS’s disaster recovery guidance describes 4 broad strategies, ordered from lowest to highest cost and complexity. The same ideas apply on any cloud or on premises.
| Method | How it works | Achievable RPO | Achievable RTO | Relative cost |
|---|---|---|---|---|
| Backup and restore | Periodic backups or snapshots copied to another location; infrastructure rebuilt at recovery time | Hours (based on backup frequency) | Hours to a day or more | Lowest |
| Pilot light | Data replicated continuously; core infrastructure exists but app servers are off until needed | Minutes | Tens of minutes to hours | Low to medium |
| Warm standby | A scaled-down but fully working copy runs all the time and scales up on failover | Seconds to minutes | Minutes | Medium to high |
| Multi-site active/active | Full environments serve traffic in 2 or more locations at once | Near zero | Near zero for most failures | Highest |
A few practical notes from the same guidance are worth repeating:
- Your RPO is set by backup frequency. Nightly backups cannot meet a 1-hour RPO, however good the tool is.
- Your RTO depends on rebuilding everything, not only data. Back up configuration, images and code too, and use infrastructure as code so environments can be recreated quickly.
- Replication is not a backup. Continuous replication gives near-zero RPO for hardware or site failures, but it also copies corruption and malicious deletions. You still need point-in-time backups with versioning.
Do not forget SaaS data
Many SaaS vendors keep their service running but expect you to protect your own data from accidental deletion, sync errors or a compromised account. Check each vendor’s backup and retention terms, and add a third-party backup where the native options do not meet your RPO.
Ransomware changes the math
Ransomware attacks your backups as well as your systems. CISA’s #StopRansomware Guide warns that many ransomware actors look for accessible backups and delete or encrypt them, and recommends keeping offline, encrypted backups of critical data and testing them regularly.
That affects your targets in 2 ways:
- Your real RPO may be older than your last backup. Attackers often sit in a network for a while before triggering encryption, so the most recent backups may already be infected. Keep enough history to go back further.
- Your real RTO is longer. You may need to investigate, clean systems and restore in a safe order. Plan for that time.
Immutable storage, separate backup credentials and copies in a separate account or location all help. Pair them with strong access controls; our guide to zero trust security covers the identity side.
Testing: the only way to know your real RTO and RPO
A target you have never tested is a guess. Schedule recovery tests by tier:
- Restore tests: Restore a sample of files, a database and a full server at least a few times a year, and time each one.
- Tabletop exercises: Walk through a scenario with the team: who decides to fail over, who talks to customers, where the runbook lives.
- Failover drills: For Tier 0 and Tier 1 systems, actually switch to the standby environment during a planned window.
- Record actual numbers: Compare measured recovery time and data loss against targets, then fix gaps or adjust targets.
Track incidents, changes and recovery tests in the same place your IT team manages its other work. Our explainer on what ITSM is shows how small teams can set that up.
Where to start this month
- List your top 10 systems, including SaaS, with an owner for each.
- Run the outage and rework questions with each owner and draft RTO and RPO.
- Group them into 3 or 4 tiers and check dependencies.
- Compare each tier with how you back it up today. Highlight any system where the backup frequency is longer than the RPO.
- Fix the biggest gaps first, starting with offline or immutable copies of critical data.
- Schedule your first timed restore test.
If you run in the cloud, recovery choices also show up on your bill as storage, replication and data transfer. Our guides to how cloud pricing works and FinOps and cloud cost optimization help you estimate those costs.
Conclusion
RTO and RPO answer different questions: how fast you must recover and how much data you can lose. Set them per system with the business owners, group systems into tiers and match each tier to a backup or disaster recovery method that can actually meet it. Then test, because the only recovery numbers that count are the ones you have measured.
Sources
- NIST CSRC Glossary: Recovery Time Objective — RTO definition from NIST SP 800-34 Rev. 1
- NIST CSRC Glossary: Recovery Point Objective — RPO definition
- NIST CSRC Glossary: Maximum Tolerable Downtime — MTD definition
- AWS, Disaster Recovery of Workloads on AWS: Disaster recovery options in the cloud — the 4 DR strategies and their trade-offs
- CISA, #StopRansomware Guide — guidance on offline, encrypted and tested backups
Frequently asked questions
What is the difference between RTO and RPO?
RTO is the maximum time a system can be down before the outage causes unacceptable harm. RPO is the maximum amount of data, measured in time, you can lose. For example, an RTO of 4 hours means service must be back within 4 hours, while an RPO of 1 hour means you can lose at most the last hour of changes. RTO looks forward from an outage; RPO looks backward.
What is a good RTO and RPO for a small business?
There is no single good number; it depends on each system. Many small businesses start with a few hours of RTO and RPO for critical systems like payments, orders and email, and 24 hours for less critical tools. Ask each process owner what an outage and lost data would cost, then pick targets you can afford to meet and test.
Can RPO be zero?
Near-zero RPO is possible with synchronous or very fast continuous replication, often across multiple sites, but it is expensive and complex. Even then, a true zero is hard to guarantee, and replication copies corruption or malicious deletion. That is why systems with near-zero RPO still need point-in-time backups to recover from data-level disasters.
Which is more important, RTO or RPO?
Neither is universally more important; it depends on the system. For payment or order systems, losing data is often worse than a short outage, so RPO matters most. For a customer-facing website with rarely changing content, quick recovery matters more, so RTO dominates. Set both for every system and let business impact decide where to spend.
How do backups affect RPO?
Your backup or replication frequency sets the best RPO you can achieve. If you back up once a night, you could lose up to a full day of data, so your RPO cannot be shorter than 24 hours. To reach a 15-minute RPO, you need snapshots, transaction log backups or replication at least that often.
What is the difference between RTO and MTD?
Maximum tolerable downtime (MTD) is the business limit: how long a process can be disrupted before serious harm. RTO is the technical recovery target for a specific system. RTO should be shorter than the MTD of the process that depends on it, leaving time to check data and resume normal work after systems come back.
How often should we test disaster recovery?
Test restores of key data and systems several times a year at minimum, and after major changes. Critical systems benefit from planned failover drills, while tabletop exercises help teams practice decisions and communication. Record the actual recovery time and data loss from each test, compare them with your targets and fix any gaps you find.
Was this guide useful
No reviews yet. Share your experience and help other readers.
Write a review
Manishdai
Manishdai writes about the technology that is reshaping every industry — from AI agents and cloud platforms to healthtech, fintech and the IT companies building it all across the United States.
manishdai.com