Disaster Recovery Planning defines how fast you must come back (RTO) and how much data you can afford to lose (RPO). The worked example computes a budget allocation across tiers.
10.1 Disaster Recovery Planning - RTO and RPO
RTO and RPO on a timeline
Strategy options by RTO target
RTO target
Strategy
Cost
Days
Backup + restore from tape / object
Low
Hours
Pilot light (core infra warm)
Low-med
Minutes
Warm standby
Medium
Seconds
Active-active multi-region
High
RPO is bounded by replication
Mechanism
Typical RPO
Periodic backup
hourly or daily
Async replication
seconds to minutes
Sync replication
near zero (latency cost)
Cross-region active
near zero with conflicts
Worked example - bank tiered DR budget
Tier
Systems
RTO
RPO
Strategy
Budget / yr
Tier 1
Core banking
1 hr
15 min
Cross-region sync
PHP 80m
Tier 2
Customer portals
4 hr
1 hr
Warm standby
PHP 25m
Tier 3
Internal apps
1 day
1 day
Backup + restore
PHP 5m
Total
~PHP 110m
DR test cadence
Test type
Cadence
Tabletop (discussion)
Quarterly
Functional restore
Every 6 months
Full failover
Annual
A plan that has never been tested is not a plan; it is a hope.
Mentor’s tip: RTO from business; RPO from data. Tiered DR budgets aligned to tiers of system criticality. Test or it is hope, not a plan - tabletop quarterly, functional every 6 months, full failover annually.
Discussion
Loading…