Topics in this domain
- IT Service Management
- Hardware Components and Architecture
- Operating Systems
- OSI Model
- TCP/IP and Common Protocols
- Network Devices: Switches, Routers, Gateways
- LAN/WAN Topologies
- Database Models and DBMS
- Database Controls and Normalization
- Asset Management
- Configuration Management
- Job Scheduling and Batch Processing
- Incident Management
- Problem Management
- Change Management
- Release and Patch Management
- Service Level Management
- Capacity and Performance Monitoring
- End-User Computing
- BCP Lifecycle
- Business Impact Analysis
- RTO, RPO, MTD, SDO
- Recovery Strategies
- Alternate Sites: Hot, Warm, Cold
- Backup Types: Full, Incremental, Differential
- Backup Storage and Rotation
- DRP Contents
- Testing BCP/DRP
- High Availability, RAID, Insurance
- Auditing BCP
RTO, RPO, MTD, SDO
Two questions after a disaster
Your laptop dies. Two questions matter straight away. How much work have I lost since my last backup? And how long until I’m working again?
The first is the recovery point objective (RPO): how much data you can afford to lose. The second is the recovery time objective (RTO): how fast you must be back. RPO looks backwards from the disaster; RTO looks forwards.
The definitions
| Metric | Meaning |
|---|---|
| Recovery point objective (RPO) | The point in time to which data must be recovered, which sets the acceptable data loss. An RPO of 4 hours means losing up to 4 hours of data is acceptable. |
| Recovery time objective (RTO) | The maximum acceptable time to restore a system or process after a disruption |
| Maximum tolerable downtime (MTD) | Also called maximum tolerable period of disruption. The longest a process can be unavailable before the impact becomes unacceptable, or threatens the organisation |
| Service delivery objective (SDO) | The level of service that must be delivered while running in recovery mode, until normal operations resume |
| Maximum tolerable outage (MTO) | The longest the organisation can keep running in recovery mode |
| Interruption window | How long the organisation can wait from the point of failure to the restoration of critical services; beyond it, losses become intolerable |
How they fit together:
- RTO < MTD. If restoring takes longer than the business can survive, the strategy fails.
- Some frameworks say MTD = RTO + work recovery time (WRT), where WRT is the time to check the systems and catch up on the backlog after technical recovery.
- SDO and MTO describe the recovery period itself: a reduced service level is acceptable, but only for a limited time.
RPO drives backups
| RPO | Typical approach |
|---|---|
| Zero or near zero | Synchronous replication, disk mirroring |
| Minutes to hours | Asynchronous replication, remote journaling, frequent incremental backups |
| 24 hours | Nightly backups |
| Longer | Weekly backups |
RTO drives the recovery setup
| RTO | Typical approach |
|---|---|
| Near zero | High availability clustering, active-active sites |
| Hours | Hot site or cloud standby |
| Days | Warm site |
| Weeks | Cold site, reciprocal agreements, vendor replacement |
Does the strategy actually meet them?
The lower the RTO and RPO, the more expensive the solution. The BIA’s cost-of-downtime analysis justifies the spend. An auditor questions two things: expensive targets nobody can justify, and targets the current strategy simply can’t meet.
Example. The BIA sets an RPO of 1 hour and an RTO of 4 hours for the order system. The DR design uses nightly backups sent to a warm site with a 48-hour rebuild. The auditor reports that the strategy meets neither objective: up to 24 hours of orders could be lost, and recovery would take two days.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Metric that determines backup frequency | RPO |
| Metric that determines the type of recovery site | RTO |
| RPO of zero requires | Synchronous replication / mirroring |
| Relationship between RTO and MTD | RTO must be shorter than MTD |
| Reduced service level acceptable in recovery mode | SDO |
| Effect of lowering RTO and RPO | Higher cost |
In short
- Recovery point objective (RPO) is the maximum acceptable data loss, measured in time; it drives backup and replication frequency.
- Recovery time objective (RTO) is the maximum acceptable time to restore a system or process; it drives the choice of recovery strategy and site.
- Maximum tolerable downtime (MTD) is the longest a process can be unavailable before the damage is unacceptable; RTO must be less than MTD.
- Service delivery objective (SDO) is the level of service to be provided in alternate (recovery) mode.
- Maximum tolerable outage (MTO) is the longest the organisation can operate in alternate mode.
- The interruption window is the time the organisation can wait from failure to restoration of critical services.
- The lower the RTO and RPO, the higher the cost of recovery.
Exam traps
- RPO is about data (how far back), RTO is about time (how fast). Don't mix them up.
- An RPO of zero needs synchronous replication or mirroring; daily backups give an RPO of up to 24 hours.
- An RTO of minutes needs a hot site or high availability; a cold site can't meet it.
- Low RTO and RPO aren't automatically better; they must be justified by the cost of downtime.
- SDO describes reduced service levels during recovery, not full service.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Two questions after a disaster
Your laptop dies. Two questions matter. How much work have I lost since my last backup? And how long until I'm working again?
The first is the recovery point objective (RPO): how much data you can afford to lose. The second is the recovery time objective (RTO): how fast you must be back.
RPO drives backups
RTO drives the recovery setup