RTO vs RPO: Definitions, a Worked Example and Veeam v13 Mapping

The difference between RTO and RPO

RTO (recovery time objective) is how long a system may stay down before the outage does unacceptable harm. RPO (recovery point objective) is how far back the recovered data may be, meaning how much data you can afford to lose. RTO runs forward from the outage, RPO backward. Set both from business impact; validate the RTO by timing a recovery and the RPO by checking the age of the restored data.

What is RTO (recovery time objective)?

RTO is the target for how long a system can stay unavailable after a failure before the outage does unacceptable harm to other systems, to the business process it supports and to that process's maximum tolerable downtime (MTD). You set it from a business impact analysis and prove it by timing a real restore.

What is RPO (recovery point objective)?

RPO is the point in time to which data must be recoverable after an outage, so it sets how much recent data you can afford to lose. A 4-hour RPO accepts losing up to four hours of changes; the backup or replication design has to keep its worst case inside that.

What the primary sources actually say

One widely cited set of definitions comes from NIST's SP 800-34 Rev. 1, the federal contingency planning guide (May 2010, with updates through November 2010, the version CSRC lists as final). Section 3.2.1 defines three downtime terms:

The NIST glossary entries for RTO, RPO and MTD come from the same publication's appendix glossary and are worded differently: the RPO entry, for instance, says data "must be recovered" where Section 3.2.1 says "can be recovered".

These definitions have three practical implications:

1. MTD belongs to the business process and RTO to the system. Each system supporting a process gets its own RTO inside the process's MTD. A footnote records that the first edition of SP 800-34 used a single term, Maximum Allowable Outage, and that MTD and RTO were introduced "to further delineate business process and information system downtime."
2. RPO sits outside MTD, as NIST states directly: "Unlike RTO, RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process."
3. Lost data still costs time. NIST gives the case where an outage stops a process mid-flight: "because it takes time to reprocess the data, that additional processing time must be added to the RTO to stay within the time limit established by the MTD." A loose RPO therefore eats into the downtime budget.

Work Recovery Time (WRT), Recovery Time Actual (RTA) and Recovery Point Actual (RPA) are practitioner terms; none appears in SP 800-34. We use RTA and RPA below for measured values, because the rest of this article keeps "objective" and "actual" apart.

Set the objectives from the business impact analysis, not from the tool

SP 800-34 derives RTO from a business impact analysis (BIA), not from what the backup product can do. Its BIA process figure (Figure 3-2, marked "Notional Times") gives an invoicing process an MTD of 72 hours and its application server an RTO of 36 hours; a budget process with an MTD of 36 hours gets a database server RTO of 12 hours. The sample BIA in Appendix B sets MTD 72 hours, RTO 48 hours and RPO 12 hours (last backup) for paying vendor invoices. NIST says the RTO must normally be shorter than the MTD so that the MTD is not exceeded, for example when data has to be reprocessed. NIST folds that time into the RTO; practitioners split it out as work recovery time (WRT), and the usual rule is that the MTD should be at least the sum of RTO and WRT. State what your RTO includes so the same phase is not counted twice.

The same chapter explains why the targets must be agreed with the business rather than simply minimised: "the shorter the RTO, the more expensive the recovery solutions cost to implement."

In Veeam's Data Trust and Resilience Report 2026 (more than 900 senior IT, security and risk leaders), 90% said they are confident they can recover from a cyber incident within their RTOs, "yet only 69% say RTOs are fully aligned with business continuity goals." An RTO never tied to the BIA can be met on paper and still fail the business.

To estimate the cost of downtime and data loss, our ransomware and downtime cost calculator takes RTO and RPO as separate inputs.

How to calculate achievable RTO: a worked example

RTA is everything between the failure and a usable service, not only the data copy. All numbers here are illustrative; replace them with your own measurements.

Scenario. An ERP service of database, application and file server VMs, 50 TiB in total, restored in full from an on-site repository. The business agreed an RTO of 8 hours.

Step 1: data transfer time. Assume the restore path sustains 70% of a 10 Gbps link. The arithmetic uses the same model as our replication window and bandwidth calculator: link speed in decimal bits, data in binary TiB.

• Effective throughput: 10,000,000,000 bit/s ÷ 8 × 0.70 = 875,000,000 bytes/s (875 MB/s)
• Data: 50 × 2^40 = 54,975,581,388,800 bytes
• Transfer: 54,975,581,388,800 ÷ 875,000,000 = 62,829.2 s = 1,047.2 minutes (about 17.45 hours)

Step 2: the rest of the budget.

15 + 30 + 1,047.2 + 60 + 15 = 1,167.2 minutes. The design misses an 8-hour RTO by 11 h 27.2 min and needs 2.4 times the agreed time. The data copy is about 90% of the total (1,047.2 ÷ 1,167.2 = 89.7%), so a faster team cannot close the gap: with detection, decision, validation and cutover all at zero, the copy alone still takes 17.45 hours. Only a different recovery mechanism, or less data to move, changes the result.

Step 3: change the mechanism. With Instant Recovery in Veeam Backup & Replication 13, the VMs run directly from the compressed and deduplicated backup files, and Veeam says workloads "are recovered in a matter of minutes." If booting them takes 10 minutes in your test, the budget becomes 15 + 30 + 10 + 60 + 15 = 130 minutes (2 h 10 min), well inside the 8-hour RTO. Until they are migrated to production storage, these VMs are "temporary spares" with "limited I/O performance". Storage vMotion can do that "without any downtime", but only if VM changes stay on the vPower NFS datastore rather than being redirected, and your VMware licence includes Storage vMotion; otherwise Quick Migration moves the VMs. Count the 130 minutes as RTA only if the application meets its performance need on the spares.

A caution on Step 1: the calculator computes transfer time over a link, but a real restore is also limited by repository reads, proxy capacity and target writes. Treat it as a lower bound, and time a real restore of a representative VM.

The example also treats the whole service as one parallel copy. A real ERP recovery often runs in order: identity and DNS, then the database, then the application, and after site loss or ransomware the Veeam server may need rebuilding first. When every tier-1 system restores at once through shared repositories, proxies and links, divide the total tier-1 data by the shared throughput. Agree when the RTO clock starts, at the failure or at the disaster declaration; detection and decision count only in the first case, but check the MTD against the full outage from the failure either way. A single-item restore, one VM, a whole site and a ransomware recovery each need their own RTO.

How to calculate achievable RPO

RPA is not the schedule interval. A restore point captures the state at the moment the job takes its snapshot, but it is only usable once that session completes. So a safe upper bound on data loss for a periodic job is the interval plus the duration of its longest session, not its typical one: a periodic full or a retried session runs longer. This assumes no run is delayed or skipped and each run produces a usable restore point.

Worked example (illustrative). A backup job runs every 4 hours and takes 40 minutes. Veeam starts counting intervals from 12:00 AM, so sessions start at 00:00, 04:00, 08:00. The 04:00 point becomes usable at 04:40; the 08:00 point at 08:40. A failure at 08:39 leaves you with the 04:00 point: 4 h 39 min of lost data. Worst case, 240 + 40 = 280 minutes, against a 4-hour RPO. If the ERP database also has transaction log backup enabled (for SQL Server in v13 the default is every 15 minutes), its recovery point can be as recent as the last completed log backup, provided the log chain back to the image is unbroken, and replaying the logs adds to recovery time.

• Move to a 3-hour interval: 180 + 40 = 220 minutes (3 h 40 min). The RPO now holds with 20 minutes of margin, as long as every session succeeds.
• A VM whose task fails, retries included, loses a full interval. Veeam retries a failed job 3 times within the session by default and retries only the failed VMs, so the others keep their new points. If the VM's 03:00 task and its retries fail and the 06:00 session succeeds, the worst case becomes 2 × 180 + 40 = 400 minutes (6 h 40 min), 1.8 times the 220. Retries that succeed still lengthen the session, which is why the rule uses the longest one. Achievable RPO therefore depends on catching failed tasks as much as on the schedule.
• After site loss, RPA is measured from the copy: if the primary repository goes with the site, the latest usable off-site restore point is what counts. A backup copy job in immediate mode copies restore points "as soon as they appear in a source backup repository." If each 3-hour run produces a 40 GiB incremental (after compression, which is what the copy moves) sent over a 500 Mbps WAN at 80% efficiency: 500,000,000 ÷ 8 × 0.80 = 50,000,000 bytes/s; 40 × 2^30 = 42,949,672,960 bytes; 42,949,672,960 ÷ 50,000,000 = 859 s, or 14.3 minutes. Off-site worst case: 180 + 40 + 14.3 = 234.3 minutes (3 h 54.3 min). On paper the RPO holds with 5.7 minutes to spare, which is no real margin. Leave more headroom than that: a longer session or copy-session overhead breaks it, and in immediate mode Veeam retries a failed copy 3 times, at 1-hour intervals when no new restore point is waiting.
• Check the RTO for the same event. If the full 50 TiB has to cross the same 500 Mbps link to come back from the off-site copy, the transfer alone is 54,975,581,388,800 ÷ 50,000,000 = 1,099,511.6 s, about 305.4 hours (12.7 days), against an 8-hour RTO. If compressed backup data crosses the link instead, use the bytes actually sent. Site loss needs its own RTA, and usually compute next to the copy (a replica, or a DR-site repository with hosts), not just a copy.

For CDP, check the configured RPO against replication lag and the age of the latest usable restore point, not a schedule interval. In the v13 CDP policy wizard, "The minimum RPO is 2 seconds", the optimal is "not less than 15 seconds" and the maximum is 60 minutes. The same page offers RPO reporting, a warning or error when new restore points are not transferred to the target within the set RPO.

Mapping Veeam v13 mechanisms to RPO and RTO

An illustration of how teams commonly combine these, not a standard:

Check every row against the worst-case rules above: under them, a daily job cannot meet a 24-hour RPO, and adding a 10-minute Instant Recovery boot to the 15/30/60/15-minute phase budget from Step 2 still totals 130 minutes.

SureBackup is often read as an RTO test, but it starts VMs directly from the backup file in an isolated lab, only a limited number at a time ("Process simultaneously up to … machines"), with a default application initialization timeout of 120 seconds. That validates recoverability within the tests that ran, not how long a full production restore takes. Time restore drills separately. Veeam's own tools for this are Veeam Recovery Orchestrator, which sets a target RTO and RPO per recovery plan and records the achieved values in its readiness-check, execution and test reports, and Veeam ONE, whose predefined alarms flag VMware VMs not backed up and backups not copied within a defined RPO (the VM alarm defaults to 24 hours, so tighten it to your RPO).

Why ransomware breaks your nominal RTO and RPO

Everything above assumes you know which restore point is good and that the backup server, identity and hypervisor survive. Ransomware can break either assumption, or both.

RPA becomes the age of the last clean restore point. Attackers can be inside before they encrypt: Mandiant's M-Trends 2026 puts the global median dwell time at 14 days, up from 11, across all intrusion types, and says the shift likely reflects attackers getting better at evading defenses. Cyber-espionage and North Korean IT-worker incidents had a 122-day median. The figure is not ransomware-specific, so read it as a warning, not a lookback window. Veeam's Scan Backup exists to "find the last clean restore point if the date of the malware attack is unknown", and Secure Restore checks restore points for malware before they reach production. Both add scan time to recovery, and a clean scan is not proof: Secure Restore, for example, restores volumes it cannot mount without scanning them. Scan Backup also has conditions: it scans backups and backup copies, not replicas; it skips backups in the SOBR archive tier and storage snapshots; a tenant cannot scan backups in a Cloud Connect repository, but the service provider can, from the Cloud Connect server; and file share and object storage backups must be created in 13.1 or later, consistent, not encrypted and not GFS.

CDP replicates encrypted writes like any other change: when a policy meets its 15-second RPO, encrypted blocks reach the replica within seconds. Recovery then depends on having a clean point within the short-term retention you configured (at most 7 days) or among the long-term restore points. Scan Backup cannot help here: it scans backups, not replicas. Long-term CDP points are capped at 95 per disk, so if you wanted long-term points to span 14 days, one every 4 hours (84 points) fits and one every 3 hours (112) does not.

Evidence also has to be preserved before systems are overwritten. CISA's #StopRansomware Guide (published October 2023) asks responders to move through its first three steps in sequence; step 9 (when no initial mitigation is possible) is to "take a system image and memory capture of a sample of affected devices", step 16 is to rebuild systems by priority, and restoring "data from offline, encrypted backups" comes at step 19, with care "not to re-infect clean systems during recovery." None of that appears in a throughput calculation.

Backups are a target in their own right: M-Trends 2026 reports that ransomware operators "actively targeted backup infrastructure, identity services, and virtualization management planes" and were "actively deleting backup objects from cloud storage." If an attacker can delete every usable copy, the RPO cannot be met. That is the argument for an immutable copy, covered in our 3-2-1-1-0 rule guide, and for checking that immutability is really enforced. Immutability is one of eight controls in What is backup security?

In Sophos's State of Ransomware 2026 (2,158 IT and security decision-makers at organizations hit by ransomware, 17 countries, surveyed January to March 2026), 16% fully recovered in less than a day, 55% within a week and 83% within a month; the average stayed at three weeks. Where data was encrypted, 66% recovered it from backups (base 1,214). Encryption slows recovery: in the 2025 edition (3,400 respondents in total), 9% of organizations whose data was encrypted were fully recovered in a day, against 24% of those where attackers did not succeed in encrypting data. And in Veeam's 2026 report, only 28% of affected ransomware victims fully recovered all affected data, recovering 72% on average.

Sophos measures whole organizations and the example one ERP service, so the figures do not compare directly. Set ransomware recovery targets from the BIA, then measure the actual recovery time and data loss in tests that include scanning, a forensic hold, a clean isolated network and a rebuilt identity plane.

What this does not tell you

• The worked examples are arithmetic on assumed inputs. 70% link efficiency, a 40-minute job and a 10-minute Instant Recovery boot are placeholders. Scaling them to other data sizes needs measurements from your own restore path.
• Survey figures are self-reported. Sophos asks how long it took to "fully recover", a phrase each respondent interprets. Veeam's full 2026 report is behind a registration form; the figures here come from Veeam's own press release, which names neither the research firm nor the fieldwork dates. Sophos's 66% backup figure allowed multiple answers, and its respondents come from organizations of 100 to 5,000 employees.
• We quote NIST, not ISO. NIST's text is public. ISO 22301 and its vocabulary standard ISO 22300 use related terms: MTPD (maximum tolerable period of disruption) where NIST says MTD, an RTO set for products, services, activities and the resources behind them rather than for one system, and MBCO, the minimum acceptable level of service during a disruption. The term summary we link quotes the older ISO 22301:2012 wording; the 2019 edition takes its vocabulary from ISO 22300. We have not reproduced ISO's copyrighted wording.
• The model is one service restored as a single parallel copy on dedicated infrastructure, with no dependencies, contention or backup-server rebuild. The estimate leaves those phases out, so measure end-to-end recovery for your real incident scenarios.
• The Veeam mapping is written for VMware vSphere. CDP and Universal CDP replicate only to vSphere, so an estate with no vSphere target (all Hyper-V, Proxmox or Nutanix, say) has no CDP tier, and agent, cloud-native and Microsoft 365 recovery times behave differently.
• Site-loss RTA is only sketched. The 305.4 hours are transfer alone. Recovery also needs DR-site compute; plan and measure failback separately.
• Dwell time is not contamination time. A 14-day median dwell time does not mean your last 14 days of backups are infected. It means the encryption date alone does not identify the clean point.

How BackupSec approaches this

Our free replication window and bandwidth calculator runs Step 1 of the worked example for your own data size, link and efficiency, and shows the seed time and daily incremental time in your browser.

For the rest of the budget, ZeroTAM advises on recovery strategy, including RTO and RPO, alongside Veeam architecture and hardening. ZeroMON tracks job and SLA status and the build and patch level of your Veeam Backup & Replication server, and reports failed sessions by email and in-app notification: a VM whose task fails after its retries adds a full interval to its RPA. ZeroPEN tests how far an attacker gets against Veeam, including backup neutralization, without deleting real backups or encrypting data, so you find out whether the backups your ransomware RTA depends on survived the attack paths we tested.