Skip to main content
< All Topics
Print
Posted
Updated

Backup & Recovery

What are RPO and RTO?

The two numbers that decide how much data you can afford to lose — and how long you can afford to be down — when disaster strikes.

The Basics

What do RPO and RTO mean?

RPO and RTO are two numbers that tell you exactly how much pain your business can absorb from an IT disaster. They aren’t technical metrics — they’re business decisions, and every good backup plan starts with defining them.

RPO — Recovery Point Objective is how much data loss you can tolerate, measured in time. If your RPO is 4 hours, you’re saying “we can afford to lose up to 4 hours of work.” That number drives how often you back up.

RTO — Recovery Time Objective is how long you can be down, measured the same way. If your RTO is 2 hours, you’re saying “we need to be back up and running within 2 hours of a disaster.” That number drives how much you invest in recovery speed.

Why it matters

Most small businesses have never had this conversation. When disaster strikes — ransomware, flood, hardware failure, accidental deletion — they discover their backup plan was built around whatever the IT person happened to set up, not around what the business can actually survive. Defining RPO and RTO up front is how you avoid that surprise.

Recovery Tiers

Not every system needs the same tolerance

A one-size-fits-all RPO and RTO wastes money on low-priority systems and under-protects critical ones. Most businesses group their systems into tiers:

Tier 1 — Mission Critical

Systems that stop the business if they go down. RPO < 15 min, RTO < 1 hr. Example: EMR, trading platforms, POS.

Tier 2 — Business Critical

Core operations, significant pain if unavailable. RPO < 1 hr, RTO < 4 hr. Example: accounting, email, CRM.

Tier 3 — Important

Inconvenient but workable if down briefly. RPO < 24 hr, RTO < 24 hr. Example: internal file shares, reporting.

Tier 4 — Tolerable

Can survive without this for days. RPO < 1 week, RTO < 1 week. Example: archives, old project data.

Shorter Windows Cost More

Every notch tighter on RPO or RTO costs more in infrastructure, licensing, and ongoing management. A 24-hour RPO might need nightly backups and a basic recovery plan. A 15-minute RPO needs continuous replication, warm standby, and automated failover. The goal isn’t the lowest possible number — it’s the right number for what the business can actually afford to lose.

How It Works

A disaster scenario — annotated

Here’s how RPO and RTO play out in a realistic incident — ransomware hits a small CPA firm at 10:30 AM on a Tuesday:

Incident Timeline — Ransomware at 10:30 AM
Example

Normal Operations
Data at Risk
Downtime
Recovered

10:00
12:30

▲ Last backup
10:00 AM
⚡ Ransomware hits
10:30 AM
✓ Back online
12:30 PM

RPO — 30 minutes of data loss
Everything entered between 10:00 and 10:30 is gone.

RTO — 2 hours of downtime
No billing, no client work, phones still ring.


Tighter RPO = more frequent backups. Tighter RTO = faster (and pricier) recovery infrastructure.

Behind the scenes: the 30-minute RPO in this example was made possible by hourly backup snapshots. The 2-hour RTO was achieved because the firm had a ready-to-go recovery image and a documented restore process. Without either, the same incident easily turns into a full day of data loss and a week of downtime — which is what most unplanned small-business recoveries actually look like.

Why It Matters

What defining RPO and RTO does for your business

Pinning down these two numbers delivers value long before any disaster actually happens:

  • Aligns IT spend with actual need — you buy the right level of protection for each system instead of under-investing or overpaying.

  • Sets clear expectations — the business and IT agree on what’s possible before an incident, not during one.

  • Drives meaningful recovery testing — measurable targets turn “did the restore work?” into “did we hit our 2-hour RTO?”

  • Satisfies compliance requirements — HIPAA, PCI-DSS, and the FTC Safeguards Rule all expect documented recovery objectives.

  • Required for cyber insurance — most underwriters now ask for documented RPO and RTO during the application process.

  • Prioritizes work during an incident — when everything’s broken, tiered objectives tell your team what to bring back first.

  • Gives a framework for vendor conversations — whether talking to an MSP, a cloud provider, or a SaaS vendor, everyone speaks the same language.

  • Quantifies the cost of downtime — forces an honest conversation about what an hour offline actually costs, which justifies the right level of investment.

The Bottom Line

RPO and RTO aren’t technical jargon — they’re the language of business survivability. Businesses that define them early build backup and recovery around real-world tolerance. Businesses that don’t find out the hard way that their backup worked, but the restore took a week.

Getting Started

How to set RPO and RTO for your business

1
List your systems and rank them by business impact. Email, line-of-business apps, file shares, phones, websites. For each one, ask: “If this were down for an hour, what does it cost us?”

2
Assign each system to a tier. Mission Critical, Business Critical, Important, or Tolerable. Most businesses find only a handful of systems are truly Tier 1 — and that insight alone saves money.

3
Define a specific RPO and RTO per tier. Be realistic — every notch tighter costs more. Document your numbers so future decisions stay anchored to what the business actually needs.

4
Match backup and recovery tools to each tier. Tier 1 systems need snapshots and rapid restore. Tier 4 archives can live on slower, cheaper storage. Your IT provider can map tools to objectives.

5
Test and revisit annually. A backup that’s never been restored isn’t a backup — it’s a hope. Run a recovery test at least once a year, measure against your targets, and adjust as the business grows.

Questions? Contact Megabyte IT Solutions
KB-BDR-001 · Backup & Recovery
Tags:
Table of Contents