RPO/RTO Specification Block
Define recovery objectives for services and systems. Document RPO (Recovery Point Objective), RTO (Recovery Time Objective), backup strategies, and disaster recovery procedures.
The RPO/RTO Specification block documents recovery objectives for services and systems. RPO (Recovery Point Objective) defines the maximum acceptable data loss, while RTO (Recovery Time Objective) defines the maximum acceptable downtime.
When to Use
Block Properties
| Property | Required | Description |
|---|---|---|
| Service/System Name | Yes | Name of the service |
| RPO | Yes | Maximum acceptable data loss window |
| RTO | Yes | Maximum acceptable downtime |
| Backup Strategy | No | How data is protected to meet RPO |
| Recovery Procedure | No | High-level steps to meet RTO |
| Test Frequency | No | How often DR tests are performed |
| Last Tested | No | Date of last successful DR test |
Understanding RPO and RTO
RPO/RTO Colour Coding
Example: Mission-Critical Database
A payment processing database with near-zero tolerance for data loss or downtime.
Example: Business-Critical Application
A customer-facing application with aggressive recovery targets.
Example: Standard Business System
An internal business system with relaxed recovery requirements.
Example: Archive System
A document archive with minimal recovery urgency.
Best Practices
Relationship to SLAs
RPO and RTO are internal objectives that support external SLA commitments. A service with a 99.9% uptime SLA (allowing approximately 8.76 hours of downtime per year) needs an RTO that enables meeting this target even with multiple incidents.