Stage 6 · Operate
Disaster Recovery & Continuity
RTO & RPO Targets
Service tiers, data-loss tolerance, recovery time objectives, and stakeholder signoff.
RTO and RPO Overview
RTO (Recovery Time Objective) is how long you can afford to be down. RPO (Recovery Point Objective) is how much data you can afford to lose. These targets drive your disaster recovery architecture and investment decisions.
definitions:
RTO:
full_name: "Recovery Time Objective"
definition: "Maximum acceptable time from disaster declaration to service restoration"
example: "If RTO is 4 hours, service must be restored within 4 hours"
drives: "Failover architecture, backup frequency, automation level"
RPO:
full_name: "Recovery Point Objective"
definition: "Maximum acceptable data loss measured in time"
example: "If RPO is 1 hour, you can lose at most 1 hour of data"
drives: "Backup frequency, replication strategy, data protection"
relationship:
description: "RTO and RPO together define your recovery capability"
example:
RTO: "4 hours"
RPO: "1 hour"
meaning: "Service must be restored within 4 hours, with at most 1 hour of data loss"Service Tiers
Not all services need the same RTO and RPO. Classify services into tiers based on business impact. Higher tiers get tighter targets and more expensive infrastructure.
service_tiers:
tier_1_critical:
description: "Revenue-generating, customer-facing services"
examples: ["Payment processing", "User authentication", "Core API"]
RTO: "15 minutes"
RPO: "0 seconds (zero data loss)"
infrastructure: "Active-active, multi-region, synchronous replication"
cost: "High"
tier_2_important:
description: "Business-critical but not immediate revenue impact"
examples: ["Internal tools", "Analytics pipeline", "Email service"]
RTO: "1 hour"
RPO: "5 minutes"
infrastructure: "Active-passive, cross-AZ, asynchronous replication"
cost: "Medium"
tier_3_standard:
description: "Useful but not critical for business operations"
examples: ["Documentation", "Internal wiki", "Development tools"]
RTO: "4 hours"
RPO: "1 hour"
infrastructure: "Single region, regular backups"
cost: "Low"
tier_4_non_critical:
description: "Nice to have, can be down for extended periods"
examples: ["Sandbox environments", "Test data", "Archived data"]
RTO: "24 hours"
RPO: "24 hours"
infrastructure: "Single region, daily backups"
cost: "Minimal"Setting Targets
target_setting_process:
step_1_identify:
- "List all services and their business criticality"
- "Identify revenue impact of downtime"
- "Identify data loss impact"
step_2_classify:
- "Assign tier to each service"
- "Map tier to RTO/RPO targets"
step_3_validate:
- "Can current architecture meet these targets?"
- "What is the cost to meet these targets?"
- "Are there technical constraints?"
step_4_negotiate:
- "Present cost/benefit analysis to stakeholders"
- "Negotiate targets based on budget and risk"
- "Document final targets with rationale"
step_5_document:
- "Create RTO/RPO register"
- "Include in service documentation"
- "Review quarterly"Stakeholder Signoff
RTO and RPO targets must be signed off by business stakeholders. These targets represent business decisions about risk tolerance. Engineering cannot set these targets alone.
signoff_process:
stakeholders:
- "VP Engineering: technical feasibility"
- "VP Product: user impact assessment"
- "CFO: cost and investment decisions"
- "CTO: technical architecture alignment"
documentation:
- "Service tier classification"
- "RTO/RPO targets per tier"
- "Cost analysis per tier"
- "Risk assessment"
- "Implementation timeline"
signoff_template: |
## RTO/RPO Target Signoff
Service: [name]
Tier: [1-4]
RTO: [time]
RPO: [time]
Business justification:
[Why this service needs these targets]
Cost implications:
[Infrastructure cost to achieve these targets]
Risk if targets not met:
[Business impact of not meeting targets]
Approved by:
- VP Engineering: [name, date]
- VP Product: [name, date]
- CFO: [name, date]
review_frequency: "Quarterly"Cost of Targets
cost_analysis:
tier_1:
RTO: "15 minutes"
RPO: "0 seconds"
infrastructure_cost: "$50,000/month"
components:
- "Active-active multi-region: $30,000"
- "Synchronous replication: $10,000"
- "Automated failover: $5,000"
- "Monitoring and alerting: $5,000"
tier_2:
RTO: "1 hour"
RPO: "5 minutes"
infrastructure_cost: "$15,000/month"
components:
- "Active-passive cross-AZ: $10,000"
- "Asynchronous replication: $3,000"
- "Backup infrastructure: $2,000"
tier_3:
RTO: "4 hours"
RPO: "1 hour"
infrastructure_cost: "$5,000/month"
components:
- "Single region with backups: $3,000"
- "Restore tooling: $2,000"
tier_4:
RTO: "24 hours"
RPO: "24 hours"
infrastructure_cost: "$1,000/month"
components:
- "Single region: $500"
- "Daily backups: $500"
total_monthly_cost: "$71,000"
annual_cost: "$852,000"Measuring Compliance
compliance_metrics:
- name: "RTO Compliance"
formula: "incidents_within_rto / total_incidents"
target: "100%"
frequency: "Per incident"
- name: "RPO Compliance"
formula: "data_loss_within_rpo / total_incidents"
target: "100%"
frequency: "Per incident"
- name: "Mean Time to Recovery"
formula: "avg(actual_recovery_time)"
target: "< tier RTO"
frequency: "Monthly"
- name: "Mean Data Loss"
formula: "avg(actual_data_loss)"
target: "< tier RPO"
frequency: "Monthly"
dashboard:
panels:
- title: "RTO/RPO Compliance by Service"
type: "table"
columns: ["Service", "Tier", "RTO", "Actual RTO", "RPO", "Actual RPO", "Compliant"]
- title: "Mean Time to Recovery (Trend)"
type: "timeseries"
query: "avg(actual_recovery_time) by (service)"
- title: "Recovery Incidents"
type: "bar_chart"
query: "count(recovery_events) by (service, result)"RTO and RPO targets represent business risk tolerance. They should be negotiated with business stakeholders, not imposed by engineering. The cost of tighter targets must be justified by the business value.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.