HD Doctor Logo

RTO and RPO Explained

Direct answer

RTO (Recovery Time Objective) is how long your company can stay down. RPO (Recovery Point Objective) is how much data you can lose. These two values defined by business (not IT) dictate the entire backup, replication and DR architecture.

Practical difference between RTO and RPO

Imagine your company suffered catastrophic failure at 2pm on a Wednesday. RTO answers: by what hour/day must we be operating again? Thursday at 8am? Friday at 2pm? In a week? RPO answers: how far back in time can we lose data? Last hour? Last night (daily backup)? Last week? Typical e-commerce: RTO 4h, RPO 15 min. Law firm: RTO 24h, RPO 24h. Hospital with medical records: RTO 1h, RPO 5 min. Each combination requires different architecture and investment.

Common definition mistakes

  1. 1.
    Let IT define RTO/RPO alone. RTO/RPO are business decisions. IT implements, but the financial impact per hour of downtime must come from CFO/CEO.
  2. 2.
    Same target for all applications. Critical OLTP system does not need the same RTO/RPO as audit log. Categorize apps into tiers (critical, important, low).
  3. 3.
    Define and not test. RTO/RPO on paper is fantasy. Test DR quarterly and adjust values based on real.
  4. 4.
    Ignore the cost of low RTO. 15-min RTO requires synchronous replication, redundant infrastructure, 24×7 team. Cost grows exponentially as RTO drops.

FAQ

How do I find the right RTO for my company?

Calculate financial loss per hour down (lost revenue + paid payroll + contract fines + reputation damage). Compare with the infrastructure cost needed to reach each RTO. The intersection of these two curves is the economically optimal point.

Is RPO of 0 possible?

Technically yes, but requires synchronous replication on every database (each commit replicates in two locations before confirming). High cost and performance impact. For 99% of companies, 5-15 min RPO via async replication is the balance.

How to measure real RTO (not theoretical)?

Full DR simulation: take down primary environment, restore from scratch, time each phase. Include auth, network, database, application. Document where it breaks. Repeat quarterly.

What is the relationship with immutable backup?

Immutable backup is INPUT to achieve RTO/RPO in a ransomware scenario. Without it, real RTO is 'after we pay ransom' or 'never'.

Can I have different RTOs in related systems?

Yes and common, but mind dependencies: app with 1h RTO that depends on DB with 4h RTO has real RTO of 4h. Map dependency chains.

Want help defining realistic RTO/RPO?

Business continuity consulting + DR design.

Next reads