What is RPO (recovery point objective)?
In simple terms, RPO is how far back in time you are willing to go when you restore. If your RPO is 1 hour, you accept losing up to one hour of new or changed data after an outage, a deletion, or a ransomware attack.
RPO is set per application, not per company. A payments database may need an RPO of minutes, while a file archive can tolerate 24 hours.
Example: a retailer backs up its order database every hour and sets a 1-hour RPO. The database fails at 2:40 pm. The last good backup is from 2:00 pm, so 40 minutes of orders are lost. That is within the RPO. If the 2:00 pm backup had silently failed, the recovery point would fall back to 1:00 pm, and the RPO would be missed. That is why the backup interval should be shorter than the RPO, as the next section explains.
What is RTO (recovery time objective)?
RTO is the maximum time a business process can be unavailable before the disruption causes unacceptable financial, operational, or legal harm. In business continuity planning, it is the deadline for getting a system back, set by the business and met by IT.
RTO covers the whole recovery, not just the restore. It includes detecting the incident, deciding to recover, restoring data, restarting applications, and confirming they work.
Example: the same retailer sets a 4-hour RTO for its order system. The outage starts at 2:40 pm. The system must be taking orders again by 6:40 pm.
RTO vs actual recovery time: RTO is the target. Recovery time actual (RTA) is what really happens. The gap between them only shows up in recovery tests, which is why testing matters as much as the target.
RPO and RTO vs RTA, RPA, MTD, WRT and MTTR
RPO and RTO are targets; the other terms measure what actually happens or set the outer limit. They often appear together in business continuity plans.
| Term | What it means | How it relates to RPO and RTO |
|---|
| RTA (recovery time actual) | How long a recovery really took | Compare with RTO after every test or incident |
| RPA (recovery point actual) | How much data was really lost | Compare with RPO after every test or incident |
| MTD (maximum tolerable downtime) | The longest outage before damage to the business can’t be reversed | RTO plus WRT must fit inside MTD |
| WRT (work recovery time) | Time after systems are restored to check data and resume normal work | Often forgotten when RTO is set too close to MTD |
| MTTR (mean time to recover) | Average actual recovery time across many incidents | Shows whether you meet RTO consistently, not just once |
RPO vs backup frequency
RPO is the business target; backup frequency is the technical setting that has to meet it. Your backup interval must be shorter than your RPO, with room for backups that run long or fail.
A 4-hour RPO with backups every 4 hours leaves no margin: one failed job doubles your real exposure to 8 hours. Backing up every 2 hours, with alerts on failed jobs, keeps you inside the target even when a job fails.
Backup duration matters too. If a backup takes 3 hours to complete, the newest usable copy is already 3 hours old by the time it is ready, so your worst-case data loss is the interval plus the run time. Faster, incremental-forever backups shrink that window.
How to calculate and set RPO and RTO targets
Set targets by working out what an hour of data loss and an hour of downtime cost each application, then choosing the point where protection costs less than the loss. A business impact analysis (BIA) is the standard way to do this.
List your applications and their owners. Include SaaS apps and identity systems such as Active Directory, Entra ID and Okta (what is identity resilience?), since nothing else can be restored without them.
Estimate the cost of downtime per hour for each one: lost revenue, lost productivity, penalties and recovery labor.
Estimate the cost of data loss per hour: the work that would have to be redone or could not be recovered at all.
Find the maximum tolerable downtime (MTD) for each process. The RTO must sit below it, with a buffer.
Set the RPO at the point where more frequent backups would cost more than the data they save.
Map dependencies. An app's RTO cannot be shorter than the RTO of the database or identity system it depends on.
Test and record actual results at least twice a year, and adjust targets or tooling where actuals miss.
Worked example: an e-commerce order system earns $50,000 an hour. The business sets an RTO of 2 hours, which caps the downtime cost of an outage at about $100,000. Re-entering or refunding an hour of lost orders costs about $10,000.
With nightly backups, worst-case data loss is a full day, or about $240,000 per incident. Assume incremental backups every 15 minutes add about $15,000 a year in storage and network costs. They cut worst-case loss to about $2,500 per incident, so they pay for themselves after a single incident.
Continuous replication with a warm standby site might add $150,000 a year to save at most $2,500 more per incident. That trade isn’t worth it for this system. (Figures are illustrative; use your own costs.)
Go deeper: Download the Modern RTO and RPO white paper to plan recovery targets across cloud, SaaS, and data center workloads.
What is a good RPO and RTO? Typical targets by tier
There is no universal "good" RPO or RTO; most enterprises group applications into three or four tiers and set targets per tier. The ranges below are common starting points, not standards.
| Tier | Example workloads | Typical RPO | Typical RTO |
|---|
| Tier 0: foundational | Active Directory, Entra ID, Okta, DNS | Minutes to 1 hour | Under 1 hour (restored first) |
| Tier 1: mission-critical | Payments, ERP, order processing, EHR | Minutes to 1 hour | Under 4 hours, including Tier 0 recovery |
| Tier 2: business-critical | Email, Microsoft 365, CRM, collaboration | 1–12 hours | 4–24 hours |
| Tier 3: non-critical | File archives, dev/test, reporting | 24 hours | 24–72 hours |
Industry shifts these ranges. Financial services and healthcare usually push Tier 1 toward minutes, because transactions and patient records are hard to recreate. Retail tightens targets around peak seasons. Manufacturing focuses on RTO for plant systems, since downtime halts production.
Not sure where your applications stand? Take the Druva Cyber Resilience Maturity Assessment to benchmark your recovery readiness.
RPO and RTO in ransomware recovery
In a ransomware attack, your real RPO is the age of your last clean backup, not your last backup. Attackers often sit in a network for days or weeks, and may encrypt or delete backups they can reach, so the newest copy may be unusable.
Cyber recovery also stretches RTO. Before restoring, teams have to scope the attack, find a clean recovery point, and make sure they are not restoring malware. That is why ransomware recovery often takes much longer than recovery from a hardware failure.
To keep RPO and RTO realistic for cyberattacks:
Keep immutable, air-gapped copies that attackers cannot encrypt or delete, even with stolen admin credentials (one layer of a multi-layered security approach).
Detect anomalies in backup data, such as unusual deletion or encryption activity, to pinpoint when an attack started and which recovery point is clean.
Recover identity first. Active Directory, Entra ID and Okta must be restored and trusted before anything else can come back.
Restore to a clean environment where you can scan data before returning it to production.
Run cyber recovery drills, not just disaster recovery drills, and measure actual times against targets.
Plan your cyber recovery: Read the Recovery Orange Book from Druva ReconX Labs, or see how Druva delivers accelerated ransomware recovery.
RPO and RTO requirements for compliance
Most regulations do not set a specific RPO or RTO number; they require you to define targets, prove you can meet them, and test them regularly. Auditors look for documented targets per system, backup and restore evidence, and test results.
| Framework | What it expects (summary) |
|---|
| HIPAA (US healthcare), 45 CFR 164.308(a)(7) | A contingency plan with data backup, disaster recovery and emergency-mode operations for patient data |
| DORA (EU financial services), Articles 11–12 | ICT business continuity and recovery plans with defined recovery objectives, backup policies and regular testing |
| PCI DSS v4.0 (payment cards), Requirement 12.10 | An incident response plan that covers recovery of cardholder data environments |
| SOC 2 (service providers), Availability criteria A1.2–A1.3 | Backup and recovery controls, and tests of recovery plan procedures, that are documented and evidenced |
| NIST SP 800-34 Rev. 1 (US federal guidance) | Business impact analysis that sets RTO, RPO and maximum tolerable downtime per system |
| ISO 22301 (business continuity standard) | Business impact analysis that sets prioritized recovery timeframes, with continuity plans that are exercised and reviewed |
| NIS2 (EU essential and important entities), Article 21(2)(c) | Business continuity measures, including backup management and disaster recovery |
In practice, compliance turns RPO and RTO from an IT setting into an audited commitment. Keep a record of every recovery test, including what failed.
How cloud backup affects RPO and RTO
Cloud backup can lower RPO by making frequent backups cheap, and lower RTO by restoring straight into cloud infrastructure instead of rebuilding hardware. The limits are network bandwidth and how much data must move during a restore.
RPO: traditional backups often run once a night because they consume so many resources, which means an RPO of about 24 hours. Cloud backups that send only changed, deduplicated data can run many times a day.
RTO: restoring a large data set back over the internet can be slow. Failing over to virtual machines in the cloud avoids that bottleneck. So does keeping recent backups on local storage: Druva TurboTier keeps a local copy for fast restores while the full backup history stays in the cloud.
SaaS apps: Microsoft 365, Google Workspace and Salesforce include limited native retention. A third-party backup sets your own RPO and lets you restore a single item or a whole tenant.
Best practices to improve RPO and RTO
Tier your applications so the tightest targets go only where the cost is justified.
Use incremental-forever backups with source-side deduplication to back up more often without overloading the network.
Automate disaster recovery runbooks so failover does not depend on people being available.
Keep at least one immutable, isolated copy for cyber recovery (the 3-2-1-1-0 rule: 3 copies, 2 media, 1 offsite, 1 immutable or air-gapped, 0 errors on restore tests).
Alert on failed backups, since one silent failure doubles your real RPO.
Test restores on a schedule, record the actual RPO and RTO, and fix gaps.
How Druva helps you meet RPO and RTO targets
Druva customers meet RPOs from minutes to one hour, depending on the workload, with a fully managed, cloud-native service and no backup hardware to run.
Lower RPO: Druva's patented source-side global deduplication sends only unique changed data, so backups run faster, use fewer resources, and can run far more often than nightly jobs.
Lower RTO: one-click automated disaster recovery fails workloads over to AWS in any region or account, and fails back on-premises when ready.
Clean recovery points after ransomware: backups are stored in Druva's secured cloud, air-gapped and immutable, with anomaly detection and delayed deletion to protect them from attackers.
Identity first: Druva Identity Resilience backs up and restores Active Directory, Entra ID and Okta, so the Tier 0 systems everything else depends on come back first.
One platform for data center, cloud, SaaS apps and endpoints, so every tier is protected and tested in one place.
Customers see the difference in real recoveries: ZS Associates cut recovery from days to just hours with Druva.
Recovery you can count on: learn about the Druva Resiliency Guarantee and compare plans and pricing.
Ready to meet your RPO and RTO targets? Talk to a Druva expert · Take a product tour · Download the RPO and RTO datasheet
FAQs
1. What is the difference between RPO and RTO?
RPO is how much data you can afford to lose, measured as time since the last good backup. RTO is how long a system can be down before the outage causes unacceptable harm. For example, a 1-hour RPO and a 4-hour RTO mean losing at most an hour of data and being back online within four hours.
2. What is the difference between RTO, RPO, MTTR and MTD?
RTO and RPO are targets you set. MTTR (mean time to recover) is the average time recoveries actually take. MTD (maximum tolerable downtime) is the longest outage before the damage to the business can’t be reversed. RTO must sit below MTD, and MTTR shows whether you meet RTO in practice.
3. Can RPO be zero?
Zero RPO means no committed data is ever lost. That requires synchronous replication, where every write is confirmed at a second site before it completes. It adds cost and latency and limits how far apart the sites can be. Most organizations reserve near-zero RPO for a few transaction systems and use frequent backups elsewhere.
4. What is the difference between RPO and backup frequency?
RPO is the business target for maximum data loss. Backup frequency is the technical setting that has to meet it. The backup interval should be shorter than the RPO, because worst-case loss equals the interval plus the time a backup takes to complete, and a failed job doubles it.
5. What is a good RPO and RTO for Microsoft 365?
Many organizations treat Microsoft 365 as Tier 2, with an RPO of 1 to 12 hours and an RTO of 4 to 24 hours. Email and files used in customer-facing work often get tighter targets. Microsoft’s native retention is not a backup, so a third-party backup is what sets your real RPO.
6. How do RPO and RTO work for SaaS apps?
In SaaS apps, RPO depends on how often your backup can pull changes through the vendor’s APIs, which may limit request rates. RTO depends on restore granularity: restoring one file or mailbox takes minutes, while restoring a whole tenant takes much longer. Test both kinds of restore.
7. How do identity, DNS and network dependencies affect RTO?
An application isn’t recovered until users can sign in and reach it. If Active Directory, Entra ID, DNS or the network come back late, a restored app is still unusable, and the real RTO stretches. Map dependencies, restore Tier 0 systems first, and test that users can actually log in and work.
8. How often should you review RPO and RTO targets?
Review targets at least once a year, and whenever you add a major application, move workloads to the cloud, change regulations or suffer a significant incident. Test recovery at least twice a year so you know your actual recovery times, not just the targets.
9. Who sets RPO and RTO: the business or IT?
The business sets RPO and RTO, because the targets reflect how much data loss and downtime the business can accept. IT designs and runs the backup and recovery systems that meet them, and reports back when a target costs more to meet than the business expected.
10. How do you explain RPO and RTO to executives?
Translate both into money and risk: RTO is how long we can be down, and RPO is how much work we can lose. Show the cost of an hour of downtime and data loss for each tier, next to the cost of meeting tighter targets, so leaders can choose the trade-off.
.png)