RTO vs RPO: The Difference, a Worked Example and Typical Tiers

RTO, the recovery time objective, is the longest a system can stay down after a failure before the business is harmed. RPO, the recovery point objective, is the most data you can afford to lose, measured as the time between your last good copy and the failure. RTO is about downtime and is met by how fast you can restore; RPO is about data loss and is met by how often you copy the data.

A quick way to remember RTO vs RPO: RTO looks forward from the failure to the moment the system works again, and RPO looks back to the moment your recovered data comes from. An order system with a 4-hour RTO and a 1-hour RPO, for example, has to be taking orders again within 4 hours of a failure and can lose no more than the last hour of orders, so it needs a copy at least every hour and a recovery method that finishes inside 4 hours. Our glossary has the full definitions of recovery time objective and recovery point objective; this guide adds a worked example, typical tiers and costs.

What is the difference between RTO and RPO?

NIST's contingency planning guide, SP 800-34 Rev. 1, defines the RTO 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, and the RPO as the point in time to which data must be recovered after an outage. Microsoft's reliability guidance describes them the same way and adds a useful habit: state both in units of time, such as four hours of data or eight hours of downtime.

How do RTO and RPO relate to maximum tolerable downtime?

NIST adds a third number, the maximum tolerable downtime (MTD): the total outage the process owner is willing to accept for a business process, all impacts considered. The RTO has to fit inside it. NIST's reasoning is practical: once a system is back, someone still has to re-enter the work done by hand or lost since the last copy, and that time counts against the MTD too, so the RTO must normally be shorter. The RPO sits outside that calculation; NIST treats it as a separate judgment about how much data loss the process can tolerate.

What does RTO vs RPO look like in a real outage?

An illustrative example, not a client: a 25-person firm sets an RPO of 1 hour and an RTO of 4 hours for its accounting server. It backs the server up every hour on the hour and sends a nightly copy to immutable cloud storage.

Data lost: the 40 minutes between the last backup and the failure, inside the 1-hour RPO. Both targets were met, and the timeline shows where the margin went: a quarter of an hour to notice and decide, most of the rest restoring and checking.

Now change one fact. The failure is ransomware, and the hourly backups sat on a network share the attacker could reach, so they were encrypted with the server. The newest clean copy is the nightly immutable copy from 11 p.m., so the real data loss is more than 10 hours, and the restore takes longer because the copy has to be checked for signs of the attacker before it is used, as NIST's incident response guidance calls for. An RPO is only as good as the newest copy the attacker cannot touch, which is why CISA's #StopRansomware guide tells organizations to keep offline, encrypted backups.

One more decision: where the RTO clock starts. Starting it at the failure, as here, counts the time it takes to notice. Many plans start it when someone declares a disaster instead, which works as long as the time to detect and decide is measured and kept short too. Pick one and write it in the plan.

What are typical RTO and RPO tiers?

Most businesses end up with three or four tiers. The ranges below are illustrative starting points for discussion, not NetSys service levels or guarantees; real targets are set system by system once each owner has answered the questions in the next section.

NIST's guide maps the same idea to impact levels: tape backup and relocation to a cold site for low-impact systems, backup plus replication and a cold or warm site for moderate ones, and mirrored systems, disk replication and a hot site for mission-critical systems.

Two published NetSys results show what tested targets look like in practice. For an international food importer, the tested failover recovery time for the ERP and SQL core is 15 minutes, down from multi-day rebuilds. For a seven-location medical practice, documented recovery time objectives went from 48 hours to 4 for the electronic health record, 72 to 8 for imaging, 24 to 1 for email and 48 to 2 for file shares, each validated by scheduled restore tests.

How do you choose RTO and RPO for each system?

1. Start with business processes, not servers. List what the business does every day, such as taking orders, billing, payroll and scheduling, and name an owner for each.
2. Ask what an hour and a day without each process costs. Ready.gov's business impact analysis is a good prompt: lost or delayed sales, overtime and expediting costs, regulatory fines, contractual penalties and customers who leave. The longest outage the owner will accept, given those costs, is the maximum tolerable downtime.
3. Map each process to its systems, including cloud applications, sign-in, the internet connection and the phones. A process is only as available as its weakest dependency.
4. Set the RTO shorter than the MTD, leaving time to re-enter work, and set the RPO from how much re-entry or loss the owner can live with.
5. Match a method and price it. Microsoft notes that an RTO and RPO of zero are tempting but difficult and costly to achieve.
6. Test, measure and adjust. Run the restore or failover and record the real time and the age of the recovered data. If the result misses the target, change the method or agree a new target with the owner.

How do you test that you meet RTO and RPO?

A backup job that reports success proves only that data was copied. To prove an RTO, restore the system to an isolated network and time every step from the point where your plan starts the clock to users working. To prove an RPO, compare the newest record in the restored data with the moment you pretended the failure happened. Include at least one restore from the offsite or immutable copy, because that is the copy you will need after ransomware. As Microsoft puts it in its guidance on disaster recovery drills, testing is how you confirm your RTO is achievable.

What targets fit a small team?

Three tiers, and as few systems as possible in the top one. For a typical small office that means:

• Hourly or more frequent backups for databases that change all day, and nightly backups for archives
• At least one copy of everything offline or immutable and offsite, so the RPO survives ransomware
• A separate backup for Microsoft 365, so mail and files have an RPO at all
• Failover only for the one or two systems whose RTO is shorter than a restore takes
• A restore test each month and a full-system test each quarter, with the times recorded

What affects cost, implementation and support?

Every step down in RTO or RPO buys a more expensive method, and NIST's advice is to find the point where the cost of downtime and the cost of recovery balance. Published list prices, as of October 2026, show the building blocks:

• Microsoft 365 data: Microsoft's own Microsoft 365 Backup lists at $0.15 per GB of protected content per month, and Microsoft notes that restore point frequency doesn't materially change the cost.
• Immutable cloud backup storage: Veeam Vault lists $14 per TB per month for its Foundation edition, including API calls and egress within a fair-use allowance for restores.
• Replication for minute-level RTOs: Azure Site Recovery lists $25 per protected instance per month for replication to Azure, plus storage, and compute while failed over.

Implementation follows the method, and support is the recurring work of checking jobs daily and running the tests that prove the targets; it is the first line to look for on a cheap quote.

How does NetSys set and prove recovery targets?

Our IT disaster recovery services set an RTO and RPO for each system with the person who owns the process, sort systems into tiers and write the agreed targets into the recovery plan. Tier 1 systems get replication with failover and a runbook; the rest get backups to offline and immutable copies, including Microsoft 365. Restore and failover tests run on a schedule, and each records the date, the scope, what restored, what failed and the measured time. A time measured in one test is evidence for that system, not a promise for every outage. Disaster recovery planning is included in every managed agreement, and agreements run month to month.

Book a call with an engineer to set RTO and RPO for your critical systems and find out whether your current backups can meet them.

Frequently asked questions

What is the difference between RTO and RPO?

RTO is how long a system can be down after a failure; RPO is how much data, measured in time, you can lose. RTO is met by how fast you restore or fail over, and RPO by how often you copy the data. A system backed up every hour can lose up to an hour of data, so it can meet a one-hour RPO whatever its RTO.

Can RPO be longer than RTO?

Yes, the two are independent. A parts catalog updated once a week might accept an RPO of a week, because the last edits are easy to redo, yet need an RTO of two hours because staff cannot quote without it. The reverse is common too: a database backed up every 15 minutes that takes a day to rebuild has a short RPO and a long RTO.

What is a good RTO and RPO for a small business?

There is no universal number. A reasonable starting point to test against is 4 hours or less of downtime and 1 hour or less of data loss for the systems the business stops without, and about a day for the rest. Then adjust after a business impact analysis and a restore test.

Does replication give you an RPO of zero?

Synchronous replication can, because each write is confirmed on both copies before it completes, at a cost in performance. Asynchronous replication can lose whatever had not been copied when the failure hit, so its RPO has to be above zero. Either way, replication copies deletions and ransomware too, so you still need backups to recover from them.

How many recovery tiers does a small team need?

Three tiers: minutes to a few hours for the one or two systems the business stops without, hours to a day for shared files and Microsoft 365, and days for archives. Meet them with frequent backups and an immutable offsite copy, adding failover only where a restore would take too long.

What affects the cost of shorter RTO and RPO targets?

Shorter RPOs need more frequent copies, more storage and more bandwidth. Shorter RTOs need faster methods: instant recovery from backup, then ready-to-start replicas, then automatic failover. Set targets per system so you pay for speed only where it earns it.