RTO and RPO Targets by Recovery Tier: What’s Realistic?

An RTO written into a business impact analysis is a target. The time the last full restore actually took is evidence. A plan that holds only the first is unproven, and the cloud providers’ own guidance says so. AWS says to “Regularly test failover to your recovery site to verify that it operates properly and that RTO and RPO are met,” and Microsoft says “production drills are the only way to verify that your plan meets RTO and RPO targets in real conditions.” The gap between declared and tested numbers is where DR programs fail audits, and where this brief starts.

Below: four recovery tiers anchored to the RTO and RPO ranges AWS publishes for its DR strategies, an honest mapping of which technology delivers each tier (Zerto, Veeam and Rubrik each earn a place, and each has limits), and diagnostics to tell whether your declared targets are real or fiction.

Four recovery tiers and what delivers them

This brief offers no benchmark numbers: a recovery target only means something when it comes from your own business impact analysis and has been tested. AWS’s guidance suggests the structure: tiers “based on their business impact (such as critical, high, medium, and low),” each with its own RTO and RPO. The table quotes the ranges AWS gives for the closest of its four multi-Region DR strategies, listed “in increasing order of cost and complexity, and decreasing order of RTO and RPO.” Those are AWS’s descriptions of each pattern, not measured benchmarks; the tier mapping is Enterprise Techie’s.

Two rules make this table useful. First, the tier is defined by the business cost of downtime, not by what the application team wants. AWS lists “recovery objectives that are more stringent than actual business objectives” among its anti-patterns, and the Tier 1 invoice is where they surface. Second, RTO and RPO travel together: a fast RTO paired with a once-a-day backup means you will be back online quickly with yesterday’s data, which for a payments platform is not recovery at all.

The reality gap: declared RTOs are fiction without testing

An untested RTO deserves a second look. If a real restore would take far longer than the declared number, then a sub-hour RTO written into the DR plan is an unfunded promise, and the declared number describes the technology the organization wishes it had bought.

The failure modes are familiar. Restore throughput is measured against a single VM, then extrapolated to hundreds. Dependencies such as DNS, identity and load balancers are not in the runbook, so the application is “restored” but nobody can log in; AWS warns that “Your workload’s objectives must be achievable given the recovery capabilities of its downstream dependencies.” And the plan has never been exercised end to end, because a full failover test is disruptive and nobody wants to own the outage. The fix is procedural, not technical: a tested tier assignment beats an ambitious untested one every time. How often each tier should be exercised, and what DORA requires of financial entities, is covered in the brief on DR testing cadence.

The takeaway for the meeting: an RTO that has never been demonstrated in a test is a hypothesis, and the board should hear it described that way.

Matching technology to tier: Zerto, Veeam, Rubrik

Vendors will happily sell you Tier 1 technology for Tier 3 workloads. Mapping honestly saves real money at renewal.

Zerto: the Tier 1 specialist

Zerto, now sold as HPE Zerto Software, built its reputation on journal-based continuous data protection: every write is replicated and logged, so you can rewind to a checkpoint from just before corruption hit; Zerto’s site describes clean restore points “each separated by only 5-15 seconds.” For genuine Tier 1 workloads, where an RPO of minutes or less is a requirement, journaled CDP is the honest answer. Zerto 10.9 added replication “between VMware vCenter and HPE Morpheus VM Essentials (HVM) environments in both directions,” which matters if Broadcom pricing has you planning a hypervisor exit for part of the estate. The limits are equally clear: “All packages are licensed per VM,” per Zerto’s license documentation, which makes it expensive to spread across the whole environment, and it is replication-first, so check whether its Extended Journal Copy feature covers your long-term retention. Fit: your top tier of workloads, not your standard.

Veeam: the Tier 2 and 3 workhorse

Veeam Data Platform v13, launched on November 19, 2025 according to Veeam’s press release, covers the backup-centered middle of the estate. Instant Recovery runs workloads “directly from compressed and deduplicated backup files” within minutes, with “limited I/O performance” until they are migrated to production storage. That makes an hours-scale Tier 2 RTO plausible from backup infrastructure, provided it has been tested at the scale you need. v13 added “Instant Recovery to Microsoft Azure” with a cleanroom to validate recoverability, and Veeam says backups are now “immutable by default.” Veeam’s continuous data protection promises “near-zero RPO” but is scoped to “mission-critical VMware virtual machines,” and instant-recovery performance depends on the repository underneath, so test on your own hardware. Fit: the bulk of the estate sitting in Tiers 2 and 3.

Rubrik: when the threat model is ransomware, not floods

Rubrik Security Cloud approaches the same problem from the security side: an “air-gapped, immutable file system,” machine-learning anomaly detection for “suspicious deletions, modifications, and encryptions,” and threat hunting that analyzes “the history of data for indicators of compromise” so you restore a clean copy instead of reinfecting yourself. Its solution pages cover Okta, PostgreSQL, Red Hat OpenShift Virtualization, Azure DevOps and GitHub. Rubrik also offers continuous data protection for VMware vSphere VMs, with “a continuous stream of recovery points” aimed at “near-zero RPOs,” so check which of your workloads that covers before ruling it out for Tier 1. The trade-off: the security analytics come with moving backup onto Rubrik’s platform. Fit: security-driven estates where the scenario you actually rehearse is a cyberattack. In a ransomware event, RTO includes the time spent proving the restore point is clean, the part of recovery Rubrik’s threat-hunting and threat containment features target.

Diagnostics: where you actually stand

Run your current plan against these thresholds:

• Declared RTO in minutes, recovery method is backup restore: you do not have a Tier 1 plan, you have a Tier 1 label. AWS describes backup and restore as “RTO in 24 hours or less”; its RTOs measured in minutes come from strategies that replicate data, starting with pilot light. Either fund CDP replication for those workloads or re-tier them honestly.
• Last tested restore took longer than the declared RTO: re-tier or re-platform. The gap will not close by itself, and an auditor will find it before you do.
• Claimed RPO in minutes on nightly backup: arithmetic says no. With one backup a day, your real RPO is up to a day; write that down or change the technology. Microsoft puts it plainly: “It’s important to make sure that the workload RPO is aligned with the backup interval.”
• No full-scale restore test in the last year: treat the declared RTO as unproven regardless of what the plan says, and schedule the test before the renewal conversation.
• Recovery copies all live on the same platform or site: your RTO is hostage to a single failure domain. The 3-2-1-1-0 rule exists precisely because restore speed means nothing if the copy you need is encrypted alongside production.

The cost curve: every tier jump costs more

The uncomfortable part of recovery tiers is the cost curve. NIST SP 800-34 Rev. 1 states the principle, “the shorter the RTO, the more expensive the recovery solutions cost to implement,” and AWS orders its DR strategies by “increasing order of cost and complexity” as RTO and RPO fall. Moving a workload from Tier 3 backup to Tier 2 replication adds replica storage, WAN bandwidth and orchestration licensing. Moving from Tier 2 to Tier 1 CDP adds journal storage, per-VM replication licensing, and in many designs a warm second site or reserved cloud capacity that sits idle waiting for a disaster. List pricing varies too much to quote a multiplier responsibly, but the direction holds, which is exactly why “everything is Tier 1” is a budget request, not a strategy.

For organizations that cannot fund a second site, DRaaS is a middle path: recovery capacity bought as a subscription, with trade-offs covered in the DRaaS pricing brief. The discipline that matters is the ratio, and AWS’s DR whitepaper is direct: “If the cost of the recovery strategy is higher than the cost of the failure or loss, the recovery option should not be put in place unless there is a secondary driver such as regulatory requirements.” Run that math and expect some of the “critical” list to move down a tier, freeing budget for proper CDP where it is genuinely needed.

Frequently asked questions

What is a realistic RTO for most businesses?

There is no single number; it comes from your business impact analysis and your last tested restore. For reference, AWS describes backup and restore as “RPO in hours, RTO in 24 hours or less.” Minute-level RTOs are realistic only for workloads protected by replication or CDP, and only if the failover has been tested end to end, dependencies included.

Can you achieve zero RPO?

In some designs. Microsoft notes that synchronous replication “can support an RPO of zero,” but “this comes at the cost of performance,” and latency grows with distance between replicas; with asynchronous replication, “your RPO must be greater than zero.” For most Tier 1 workloads, near-zero RPO from asynchronous CDP is the practical target, and the savings are better spent on testing.

Is a lower RTO always better?

No. Every hour you shave off an RTO costs more, and past a certain point the spend exceeds the downtime cost it avoids. NIST SP 800-34 calls the crossover the cost balance point and says it “will be different for every organization and system.” Find yours from the business impact analysis rather than from a rule of thumb.

How often should RTO and RPO targets be tested?

As a starting point (Enterprise Techie’s suggestion, not a benchmark): quarterly failover tests for Tier 1, twice a year for Tier 2, and an annual full restore test for everything else. Some regulated firms have a floor set for them: DORA requires EU financial entities other than microenterprises to test systems supporting critical or important functions “at least yearly,” as the DR testing cadence brief explains.

Enterprise Techie sends vendor-honest analysis like this once a week: get the brief by email, free.

Buying? Start from RFPhub’s free DRaaS RFP template.