What is RTO and RPO?

RTO and RPO are the two metrics that translate "how important is this data" into actual backup architecture decisions. They sound similar; they're not.

RTO — Recovery Time Objective

How long can the business tolerate being down? Measured in hours or days.

• RTO of 1 hour — service must be back within an hour. Requires instant virtualization, hot standby systems, or aggressive automation. Expensive.
• RTO of 4-8 hours — common business-day target. Requires fast restore capability (image-based backup with local appliance).
• RTO of 24-48 hours — acceptable for non-critical systems. Standard backup-and-restore works.
• RTO of 1+ weeks — rare in business contexts; mostly archive scenarios.

RPO — Recovery Point Objective

How much data can the business afford to lose? Measured by the time between backups.

• RPO of 15 minutes — backups every 15 minutes. Requires continuous data protection or frequent snapshots. Expensive at scale.
• RPO of 1 hour — hourly snapshots. Common for transactional systems.
• RPO of 4 hours — balanced for most business workloads.
• RPO of 24 hours — daily backup. Standard for less critical workloads.

Worked example

A 30-person professional services firm decides their accounting system needs RTO of 4 hours and RPO of 1 hour. That translates to:

• Image-based backup on a local appliance (fast restore = meets RTO)
• Hourly snapshots of the accounting application (meets RPO)
• Daily replication to cloud (offsite protection per 3-2-1)
• Quarterly restore tests to verify RTO/RPO are actually achievable

Same firm decides their file shares can tolerate RTO of 24 hours and RPO of 24 hours — standard daily cloud backup suffices.

The tradeoffs

Lower RTO and RPO = better protection but higher cost. Most organizations have a mix: aggressive RTO/RPO for revenue-critical systems, relaxed for less critical. Right-sizing this is where backup architecture earns its keep.