RTO vs RPO: what they mean and how to set them for your business

The short version: RTO (recovery time objective) is how long you can afford to be down after an incident. RPO (recovery point objective) is how much recent data you can afford to lose, measured as time. RTO is about restoring the service. RPO is about the age of the data you restore. Your backup frequency sets your RPO, and your restore method sets your RTO.

Most small and mid-sized businesses own a backup and have never written down how fast it must come back or how much data it may lose. Then something fails, and the first real conversation about those numbers happens during the outage. This guide explains RTO and RPO in plain terms, shows how to work out realistic targets, and explains how each one drives what you pay for in backup and recovery.

For the formal definitions we used the NIST glossary entries sourced from NIST SP 800-34 Rev. 1, the contingency planning guide for federal information systems: recovery time objective and recovery point objective. We read both on 28 October 2026 (checked 2026-10-28). The examples below are illustrative, with invented numbers, and are not Brocent results.

What is the difference between RTO and RPO?

Two questions after any failure: how long until we are working again, and how much work did we lose?

• RTO answers "how long can we be down?" NIST describes it as the overall length of time a system's components can be in the recovery phase before the organization's mission or business processes are negatively affected.
• RPO answers "how much data can we lose?" NIST describes it as the point in time to which data must be recovered after an outage.

An RPO is easiest to picture on a timeline. If the system fails at 15:00 and the last good copy of the data is from 12:00, you will lose three hours of changes. If your RPO is one hour, that gap is two hours too long.

An RTO is the length of the bar from the failure to the moment users can work again. If the failure is at 15:00 and your RTO is four hours, the target is that users can work again by 19:00.

They are independent. A business can need near-zero data loss and tolerate a day of downtime (a ledger that can be offline overnight but must never lose a posted transaction), or it can need the service back in minutes and accept losing the last hour (a reporting site that is rebuilt from source every hour).

How does backup frequency set your RPO?

Your RPO can never be better than the gap between your good copies. If you take a backup once a night, the worst case is that you lose almost a full day of work.

Worked example. A finance team's accounting server is backed up every night at 22:00. The server's storage fails at 17:00 the following afternoon.

1. The last good backup is from 22:00 the night before.
2. The time between that backup and the failure is 19 hours.
3. The team has lost 19 hours of entries, even though the backup job ran successfully every single night.

The effective RPO of a nightly backup is therefore up to 24 hours, not "zero because we have backups". If the business decides it can only lose one hour, the backup interval has to be an hour or less. That means more frequent snapshots, continuous replication, or application-level logging, and each step costs more in storage, licensing and bandwidth.

A useful rule: backup interval ≤ RPO, and then add a margin for failed or delayed jobs. A backup that is scheduled hourly but fails silently for six hours has an effective RPO of seven hours. This is why monitoring backup jobs matters as much as scheduling them.

What determines your RTO?

RTO is not a single action. It is the sum of several steps, and the slowest one usually surprises people.

1. Detect: someone or something notices the failure.
2. Decide: a person with authority chooses to fail over or restore, and declares it.
3. Restore: data and systems are rebuilt from backup or switched to a standby.
4. Verify: the restored service is tested before users are let back in.
5. Cut over: users and integrations are pointed to the restored service.

The restore step is often the largest, and it depends on how much data there is and how fast it can be moved.

Worked example. You must restore 2 TB of data from a cloud backup. 2 TB is about 16,000 gigabits. Ignoring all overhead:

• At an effective 1 Gbps, the transfer takes about 16,000 seconds, which is roughly 4.4 hours.
• At an effective 200 Mbps, it takes about 80,000 seconds, which is roughly 22 hours.

Real restores are slower than this because of compression, small files, verification and contention with other traffic. The point is that an RTO of four hours is impossible with a 200 Mbps link and a pure cloud restore of that size. To meet it you would need a faster link, a local copy for fast restores, a smaller restore scope (the critical data first), or a standby environment that is already running.

How do you set RTO and RPO for each system?

Do not choose one number for the whole company. Different systems matter differently, and treating them all as critical makes the plan unaffordable. Work through this list for each system.

1. List the systems and the business processes that depend on them: payroll, email, the ERP, the file share, the CRM, the website.
2. For each process, ask how long it can stop before real harm starts (lost sales, missed legal deadlines, idle staff). That is your candidate RTO.
3. Ask how much recent work could be re-entered or recreated by hand, and for how long. That is your candidate RPO.
4. Group the systems into tiers, for example "must be back within hours", "within a day" and "within several days", so you pay for fast recovery only where it matters.
5. Check the technical reality: does the backup interval meet the RPO, and does the restore method meet the RTO, including the throughput maths above?
6. Cost it. Tighter targets need more frequent copies, more storage and often a standby environment. If the price is too high, either relax the target or accept the risk explicitly.
7. Write the agreed targets down, have the business owner sign them off, and review them at least once a year or when a system changes.

Step 6 is where many plans fail. A target nobody has costed is a wish, not a target.

What might the tiers look like for a 40-person company?

The figures below are invented to show the method. Your own answers will differ.

1. Tier 1: accounting system and order system. RTO 4 hours, RPO 1 hour. Lost transactions are hard to recreate, and sales stop while the system is down. This tier needs hourly copies, a local restore copy so the transfer does not depend on the internet link, and a tested restore procedure.
2. Tier 2: file share and CRM. RTO 1 business day, RPO 4 hours. Staff can work from local files for a while, and recent edits can be redone. A snapshot every 4 hours during the working day plus a nightly backup is enough, restored from the cloud.
3. Tier 3: intranet, archive and test systems. RTO 3 business days, RPO 24 hours. A nightly backup and a restore when time allows.

Notice that the tiers are driven by the business question first and the technology second. The company pays for hourly copies and a local restore point for two systems, not for everything.

How do RTO and RPO relate to disaster recovery, BCP and MTTR?

• Business continuity plan (BCP): the wider plan for keeping the business running through a disruption. RTO and RPO are the technical recovery targets inside it.
• Disaster recovery (DR): the technical part of the plan: how systems and data are brought back. DR is where RTO and RPO are met or missed.
• Maximum tolerable downtime: a related NIST term for the longest outage the business can survive at all. RTO has to be shorter than it, with room left for verification and cut-over.
• MTTR: the average time recoveries have actually taken in the past. RTO is a target you set; MTTR is a measurement. If your measured recovery time is consistently longer than your RTO, the target is not real. Our guide to MTTR, MTBF and MTTA explains how to measure it.

Is RTO the same as the response time in an SLA?

No, and this confusion is common. An SLA response time says how fast a support engineer will start working on your ticket. RTO says how fast the service must be back. An engineer can respond in 15 minutes and still need hours to restore a large system.

Brocent's published SLA targets cover response and resolution times by priority: for a critical (P1) ticket, a 15-minute first response and an 8 business hour resolution target. The P1 to P4 priority guide explains how those levels work. Neither replaces an RTO for a given system. Ask for your recovery targets separately, and ask how they will be tested.

Why test recovery, and not just back up?

An untested backup has an unknown RTO and an unknown RPO. The only way to turn the numbers on paper into numbers you can trust is to run a restore and time it.

Test at least the following:

1. Restore one critical system into an isolated environment and time it from the start of the request to a working login.
2. Check the age of the data after the restore against the RPO.
3. Test a restore with the people who would do it during an incident, using the documentation they would have.
4. Record what went wrong, fix it, and test again.

Our cloud managed backup service is designed around this. According to the service page, the backup policies are calibrated to your RTO and RPO, backup jobs are monitored 24x7, and recovery drills are run regularly to verify integrity. If you want those targets turned into a backup design for your own environment, the page explains the options and the assessment.

Where can you see Brocent's published service levels and prices?

Support response targets are on the SLA page, and the managed IT support plans and per-user pricing shows the managed IT support list prices and a 15-minute first response on critical incidents within the service window in your contract. If you want to talk through RTO and RPO for your systems, contact us. For how a large outage should be run once it happens, see major incident management.

Frequently asked questions

What does RTO stand for?

RTO stands for recovery time objective: the maximum time a system can be out of service in the recovery phase before the business suffers unacceptable impact. It is a target you set, in minutes or hours.

What does RPO stand for?

RPO stands for recovery point objective: the point in time to which data must be recovered after an outage. In practice it is the maximum acceptable age of the data you restore, so an RPO of one hour means losing at most the last hour of changes.

Which is more important, RTO or RPO?

Neither is more important in general. It depends on the system. A payments or ordering system usually cares most about RPO, because lost transactions cannot be recreated. A customer-facing website may care most about RTO, because every hour offline loses visits. Set both per system.

Can RTO and RPO be zero?

In theory, but it costs a lot. Near-zero RPO needs continuous replication, and near-zero RTO needs a standby that takes over automatically. Both add cost and complexity, and they do not protect against errors that replicate to the standby, such as accidental deletion or ransomware. Most businesses use tiers instead.

How often should we back up to meet an RPO?

At least as often as the RPO, with margin for failed jobs. For a one-hour RPO, take a copy at least every hour and monitor that each job completes. A nightly backup cannot meet an RPO of a few hours.

Does cloud backup meet a short RTO?

Not by itself for large data sets. Restore speed depends on how much data you must bring back and how fast it can travel. For a short RTO you may need a local copy, restore the critical data first, or keep a standby environment.

How often should RTO and RPO be reviewed?

At least once a year, and whenever you add or change a major system, move to a new cloud service, or grow significantly. Test a restore at the same time, so that the targets stay tied to something measured.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.