CompTIA Security+ guideHigh-value skills
RTO vs RPO for Security+: Recovery Metrics Explained
Use one outage clock to see a 120-minute recovery time objective met and a 30-minute recovery point objective missed.
Short answer
RTO is how long the service may stay down. RPO is how much data, measured in time, you can afford to lose. On this timeline the outage lasts 70 minutes against a 120-minute RTO, so the time target is met. The only backup is 75 minutes old against a 30-minute RPO, so the data target is missed. MTTR on the objectives is mean time to repair. The acronym list also expands MTTR as mean time to recover. Say which meaning you are using. MTBF is an average time between failures, not a promise the part will last that long.
Four words, two clocks
SY0-701 lists recovery time objective (RTO), recovery point objective (RPO), mean time to repair (MTTR), and mean time between failures (MTBF) together. The acronym glossary on the same PDF expands MTTR as “Mean Time to Recover.” The body says repair. Both expansions are printed by CompTIA. In this article, MTTR means the time to restore the service in the scenario, and that choice is stated each time. Do not silently switch among repair, recovery, and ticket resolution.
RTO is a downtime target. RPO is a data-loss target. Neither one is the dollar figure in the risk calculation guide. How you decide the next incident step is the incident response guide.
The timeline
Assumptions, all of them required: the last recoverable backup finished at 08:45. The outage starts at 10:00. Service is restored at 11:10. There is no replication and no log replay. This backup is the only copy you can restore.
| Clock | Interval | Target | Result |
|---|---|---|---|
| 10:00 to 11:10 | 70 minutes of downtime | RTO 120 minutes | Met. 70 is within 120 |
| 08:45 to 10:00 | 75 minutes of work that the backup does not contain | RPO 30 minutes | Missed. 75 is more than 30 |
| 10:00 to 11:10 | 70 minutes to restore service | MTTR, used here as time to restore this service | 70 minutes observed. It is not the RTO. The RTO is the allowance. This is the outcome |
| Not on this clock | Average time between failures for a component | MTBF | Not measured by one outage |
RPO is not how long the restore takes. The restore took 70 minutes. The data gap is the 75 minutes between the backup and the failure. Meeting RTO while missing RPO is normal when the backup is older than the data target and the restore itself is still fast enough.
Three shorter cases
1. Backup at 09:40, failure at 10:00, restore at 10:50. RPO 30 minutes, RTO 2 hours. Data gap is 20 minutes, so the RPO is met. Downtime is 50 minutes, so the RTO is met. Change the backup to 09:00 and the RPO is missed at 60 minutes, while the RTO is unchanged.
2. A disk vendor quotes an MTBF of 1,000,000 hours. That is an average from a population, not a warranty that this disk runs for 1,000,000 hours. It does not set the RPO. Backup frequency sets how old the recovered data will be.
3. A ticket system shows “resolved” 6 hours after an outage because the write-up was finished then. If MTTR in your procedure means time to repair the service, and the service was back in 40 minutes, the 6 hours is documentation time. Say which definition the question is using. The objectives give you both “repair” and “recover,” so the stem has to make the meaning clear before a number is right or wrong.
Practice a Security+ item that asks which target failed. The free set will not compute your company’s real RPO.
Trust the source
Official sources
Exam policies can change. Use these primary sources for the most current details.