RTO and RPO RTO/RPO

RTO and RPO are the two numbers that drive every backup and disaster-recovery decision worth making. They’re often confused; they’re related but distinct.

RTO — Recovery Time Objective

How long can the business tolerate being down before the cost of downtime becomes intolerable? Measured from the moment of the incident to the moment of full restoration of service.

Examples:

• An e-commerce shop: RTO might be 1 hour. Beyond that, every hour costs measurable lost sales.
• An accounting firm during tax season: RTO might be 4 hours. Beyond that, deadlines start slipping.
• An accounting firm in July: RTO might be 24 hours. There’s slack.
• A nonprofit running once-a-month operations: RTO might be 72 hours. Most of the time, no users are affected.

RPO — Recovery Point Objective

How much data loss is acceptable? Measured from the most recent recoverable backup to the incident. If you back up nightly and the incident hits at 5 PM, your RPO is up to 24 hours of data loss (everything since last night’s backup).

Examples:

• An e-commerce shop: RPO of 5 minutes. Lost orders are lost revenue.
• A medical practice: RPO of 1 hour. Charts and appointment changes accumulate fast.
• A general law firm: RPO of 24 hours. End-of-day backups capture the day’s work.
• A static marketing website: RPO of 7 days. Content rarely changes; weekly backup is fine.

Why the numbers matter

The numbers drive the architecture. Tighter RTO and RPO cost more in tooling and operational discipline.

• RTO of 1 hour requires hot standbys, replicated databases, automated failover, and tested runbooks. You can’t get there by restoring tape.
• RPO of 5 minutes requires continuous data protection — transaction-log replication, near-real-time replication, or journaling.
• RTO of 24 hours and RPO of 24 hours is achievable with nightly snapshots and a manual recovery process. Most SMBs land here.

The mistake we see most often

The mistake is not having the conversation at all. Backup gets set up once, the metrics are never explicitly defined, and the first time anyone discovers the actual RTO/RPO is during an incident — usually when the answer is much worse than the business assumed.

For our managed clients we document RTO and RPO in the contract, test-restore against those numbers quarterly, and update the targets when the business changes (a growing e-commerce shop’s RPO tightens; a sleepy practice’s RTO loosens). The numbers are also what gets handed to cyber-insurance underwriters as evidence of a documented disaster recovery plan.