RPO and RTO in Plain English

A Destin e-commerce company told their backup vendor they needed "fast recovery." The vendor sold them a solution with 4-hour RTO. What the vendor didn't ask: the company's internet connection was 50Mbps. Their data was 3TB. Restoring 3TB over 50Mbps takes about 5 days, not 4 hours.

They paid for gold-level service they physically couldn't use.

RPO and RTO are two numbers. Before buying any backup technology, you need to know what they actually are for your business.

RPO: Recovery Point Objective

RPO is how much data you can afford to lose.

It's measured in time. If backups run at midnight and your server fails at 5pm, you've lost about 17 hours of data.

The question to ask: If our systems went down right now, how much data would we lose? How far back would we have to go to get to clean data?

Common RPOs:

• Real-time (RPO = 0): Every transaction is captured immediately. Used for financial systems, point-of-sale, trading platforms. Very expensive.
• 15 minutes: Maximum acceptable data loss is 15 minutes. Requires continuous backup or near-real-time replication. Expensive.
• 1 hour: Backing up every hour. Common for businesses with moderate data churn. Moderate cost.
• 4 hours: Daily backup cycle with a midday backup. Common default. Lower cost.
• 24 hours: Daily backup. Some data loss acceptable. Lower cost.
• 1 week: Weekly backup only. Significant data loss risk. Only acceptable for non-critical data.

How to determine your RPO:

Ask your team: "If we lost everything from the past [time period], what would we lose? Would we lose business? Would we lose customers? Would we face legal liability?"

If the answer is "we'd lose some efficiency," your RPO can be longer. If the answer is "we'd lose years of client records," your RPO needs to be shorter.

RTO: Recovery Time Objective

RTO is how long you can afford to be completely down.

If your server fails at 9am and you're back online at 5pm, your RTO was 8 hours.

The question to ask: How long can we be closed before this becomes a business-ending problem?

For a restaurant, 4 hours of downtime might mean losing $10,000 in Saturday dinner service. For an e-commerce company, 4 hours might mean $50,000 in lost sales. For a law firm, 4 hours might be annoying but survivable.

Common RTOs:

• Under 1 hour: Critical operations. Requires hot standby, local backup, tested procedures, possibly duplicate infrastructure. Very expensive.
• 2-4 hours: Business-critical systems. Requires local or fast cloud backup with documented procedures. Moderate to expensive.
• 8-24 hours: Standard business. Cloud backup with documented procedures. Moderate cost.
• 1-3 days: Can tolerate downtime. Basic cloud backup. Lower cost.
• 1 week+: Rebuild from scratch acceptable. Basic file sync. Lowest cost.

How These Two Numbers Drive Your Backup Strategy

RPO drives backup frequency. If you need 1-hour RPO, you need backups at least every hour. If you can tolerate 24-hour RPO, daily backups are sufficient.

RTO drives restore infrastructure. If you need 2-hour RTO, you need fast local restore capability. If you can tolerate 24-hour RTO, cloud restore is acceptable.

The mismatch that kills businesses: Buying cloud backup with 1-hour RPO (continuous backup) but having a slow internet connection that makes actual restore take days. Or buying "fast" local backup but never testing it, so when you need it you discover the restore process is undocumented and slow.

The formula for realistic restore time:

Actual restore time = Time to access restore interface
                    + Time to locate correct backup
                    + Time to initiate restore
                    + Data transfer time
                    + Time to verify restore
                    + Time to bring systems online

For a typical SMB with 1TB of data and 100Mbps connection: data transfer alone is 22+ hours. A 4-hour RTO is physically impossible with pure cloud restore.

What It Costs

RPO costs:

• 24-hour RPO (daily backup): $0-10/month (basic cloud backup)
• 4-hour RPO: $20-50/month (more frequent backup scheduling)
• 1-hour RPO: $50-100/month (continuous backup, larger bandwidth usage)
• Real-time RPO: $100-300/month (real-time replication, dedicated infrastructure)

RTO costs:

• 24-48 hour RTO: $0-20/month (cloud backup, standard restore)
• 8-24 hour RTO: $50-100/month (faster cloud tier, priority restore)
• 2-4 hour RTO: $200-500/month (local backup appliance, hot standby)
• Under 1 hour RTO: $1,000+/month (disaster recovery as a service, duplicate infrastructure)

Example combinations:

• 24h RPO / 48h RTO: Basic cloud backup. $7-20/month. Acceptable for businesses where downtime is inconvenient but survivable.

• 4h RPO / 8h RTO: Business backup with frequent scheduling. $50-100/month. Appropriate for businesses where downtime costs money.

• 1h RPO / 2h RTO: Business continuity solution. $300-600/month. Appropriate for businesses where downtime threatens survival.

What Can Go Wrong

You set an RTO that's physically impossible. A 4-hour RTO with 3TB of data over a 50Mbps connection. Solution: Calculate your actual restore time before committing to an RTO.

You set an RPO that's too aggressive for your bandwidth. You need 15-minute RPO but your upload speed is 10Mbps. Backup can't complete in 15 minutes. Solution: Know your bandwidth and data change rate.

You buy backup technology that doesn't match your RTO. You buy cloud backup for a 2-hour RTO requirement. In an emergency, you discover the restore process is undocumented and takes 18 hours. Solution: Test actual restore time before you need it.

Your RTO assumption was wrong. You assumed 24 hours of downtime was fine. Then your server failed and you discovered you had 12 hours of quotes due that day. Solution: Ask the hard question upfront. What actually happens if we're down?

Your RPO assumption was wrong. You assumed losing a day of data was acceptable. Then the restore revealed corruption that had been propagating for a week. Your "clean" backup was already contaminated. Solution: Verify data integrity, not just backup completion.

Vendor Questions (Copy/Paste)

1. "With our data size and internet speed, what's our realistic RTO? Not the SLA number — the actual restore time if we needed to restore today."
2. "What's your RPO with continuous backup vs. hourly backup? What's the cost difference?"
3. "Can we test a restore before signing a contract? Not a demo — an actual test with our data."
4. "What's included in your RTO guarantee? Does it include data verification and system restart, or just data transfer?"
5. "If we need to restore on a weekend, what's the process? How long does it take?"

Minimum Viable Implementation

1. Write down your RTO and RPO for each critical system. Not "fast" — a specific number. "Our file server: 24-hour RPO, 24-hour RTO." "Our accounting system: 4-hour RPO, 8-hour RTO." Different systems may have different requirements.

2. Calculate your actual restore time. For each system: how long would it take to restore from your current backup? Is this faster or slower than your RTO? If slower, you have a gap.

3. Match backup technology to your RTO. If you need 2-hour RTO but your restore takes 18 hours, you need faster restore infrastructure — local backup, hot standby, or managed recovery services.

4. Test annually. Pick a system, simulate failure, measure how long actually restoring takes. Compare to your RTO. If they don't match, fix your strategy.

5. Review quarterly. As your data grows and your business changes, your RTO and RPO requirements may change. Review annually at minimum.

When to Hire Help

• You've never defined RTO and RPO for your business
• Your current backup solution doesn't meet your RTO requirements
• You have multiple systems with different RTO requirements
• You're unsure whether your internet speed supports your backup strategy
• You've had downtime and discovered your RTO assumptions were wrong
• You have compliance requirements (HIPAA, FINRA) that mandate specific RTOs

Most Gulf Coast SMBs can define RTO and RPO themselves with a simple conversation: "How long can we be down? How much data can we lose?" The answers don't require technical expertise — they require business judgment.

Write the numbers down. Then build a backup strategy that actually meets them.