Business Continuity Metrics: RPO, RTO, MTBF, MTTR + Site Types

Why this is on N10-009

CompTIA moved business-continuity vocabulary heavily into N10-009. Expect scenario questions like “The CFO says the org can lose no more than 15 minutes of transactions. Which metric is she describing?” The answer is RPO, not RTO. You need to know the difference cold.

The four metrics

RPO: Recovery Point Objective

How much data are you willing to lose?

Measured in time: “15 minutes of transactions” or “24 hours of email”. RPO directly drives your backup frequency. If RPO = 1 hour, you back up (or replicate) at least every hour.

Mental picture: RPO is a line drawn backwards from the outage. Everything between that line and the outage is data lost.

Backup     Backup     Backup   [OUTAGE]
  |----1hr---|----1hr---|----1hr---→   RPO = 1 hour
                             ↑
                       up to 1hr of data lost

RTO: Recovery Time Objective

How long can you be down?

Measured in time: “4 hours to bring the payroll system back up”. RTO drives the DR architecture: cold site (long RTO OK), hot site (minutes RTO required).

Mental picture: RTO is a line drawn forward from the outage. If you’re not back up by then, you missed SLA.

[OUTAGE] ..... service restored
         ↑         ↑
         start     RTO = time-to-recover

MTBF: Mean Time Between Failures

How often does this piece of gear fail?

Reliability metric from the manufacturer. Higher = more reliable. A router with MTBF 200,000 hours will, on average, fail every ~23 years. You use MTBF for capacity planning and spare-count decisions.

MTTR: Mean Time To Repair (or Restore)

When it fails, how long to fix?

MTTR includes detection + travel + repair + verification. If MTTR is 4 hours and MTBF is 200,000 hours, availability ≈ MTBF / (MTBF + MTTR) → very close to 100%.

Site types (DR)

If the exam scenario says “tight RTO, budget-constrained, mostly-idle DR” → cloud DR. If it says “regulatory requirement for near-zero downtime” → hot site. If it says “large industrial with days-long tolerance” → cold site.

Related terms you’ll see

• MTBSI: Mean Time Between System Incidents. Similar to MTBF but for the system, not the component.
• SLA (Service Level Agreement), the contractual availability target. “Four nines” = 99.99% = 52 minutes downtime/year.
• BCP (Business Continuity Plan), the whole document that says what stays running during a disaster.
• DRP (Disaster Recovery Plan), the technical playbook to restore IT after a disaster. Subset of the BCP.

Common exam traps

1. Confusing RPO with RTO. RPO = data loss tolerance (looks backward). RTO = downtime tolerance (looks forward). This is the #1 tested distinction.
2. Assuming a hot site means zero data loss. A hot site with async replication still has an RPO > 0. Only synchronous replication gets you RPO = 0 (and it’s expensive at latency-sensitive distance).
3. Mixing up MTBF and MTTR. MTBF is between failures (reliability). MTTR is during a failure (recovery). Both are means / averages.
4. Ignoring people/process cost. DR isn’t just gear. The exam expects you to know that runbooks, training, and failover drills are part of BCP.

Real runbook shape

A production DR runbook typically has:

• Trigger criteria (what counts as a disaster?)
• RPO / RTO targets per system
• Roles + call tree
• Failover steps (per system, in dependency order)
• Failback steps (once primary is restored)
• Post-incident: RCA + runbook update

Cheat strip

RPO  backward  data loss tolerance   drives backup freq
RTO  forward   downtime tolerance    drives DR site type
MTBF between failures                reliability (high=good)
MTTR during a failure                recovery speed (low=good)

Cold  space only          days       cheap
Warm  partial gear        hours      middle
Hot   live mirror         minutes    expensive
Cloud DR  pay-per-use     variable   flexible

BCP = the whole plan  |  DRP = the technical subset
SLA "four nines" = 99.99% = 52 min downtime/year

How a US employer asks this on the Network+ or a junior interview

In a US helpdesk-to-NOC interview the question almost always arrives in two shapes:

1. “The CFO says we can lose at most 15 minutes of transactions. Which metric is that?”
2. “Our MTBF on this cluster is 60 days, MTTR is 2 hours. What is our availability?”

For #1 the answer is RPO: data loss tolerance looks backward from the outage. For #2 availability = MTBF / (MTBF + MTTR) = 1440 / 1442 = 99.86%. That is “three nines” territory, not “four nines”. A US employer uses this to see whether you understand that nines are expensive and that “four nines” means 52 minutes of yearly downtime (see RTO vs MTTR explained in the blog).

Common US industry benchmarks worth memorizing before an interview:

• Retail e-commerce storefront: RTO 1 hour, RPO 15 min, three-to-four nines
• Hospital EHR: RTO 15 min, RPO 1 min, four-plus nines, HIPAA audit tie-in
• SMB internal file server: RTO 1 day, RPO 1 day, two nines is fine
• DoD / FedRAMP cloud workloads: RTO measured by FIPS 199 impact level, RPO per CJCSI 6510

If you are studying Network+ (N10-009) specifically to clear a DoD 8140 or similar US federal baseline, Network+ is the typical IAT Level II baseline cert. The RTO / RPO vocabulary shows up in the “Security Concepts” domain and in RMF documentation your team will own.

FAQ

What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is how long you have to be back up after an outage. RPO (Recovery Point Objective) is how much data you can afford to lose. RTO looks forward from the outage, RPO looks backward.

Is a four nines SLA realistic for a small US business?

Four nines (99.99%, 52 min of downtime a year) is realistic only with hot-site failover, redundant power, and 24x7 on-call staff. Most SMBs run two or three nines and buy insurance for the rest. If a vendor sells you four nines without redundancy on the plan, the SLA is theatre.

Which site type do most US SMBs actually run?

Warm sites with cloud DR as a backstop. A warm site is partially provisioned (hardware ready, data replicated hourly) so RTO is a few hours. Pure cold sites (empty space) have mostly disappeared since AWS and Azure made spin-up-on-demand practical.

Does MTTR include detection time?

Officially yes. MTTR (Mean Time To Repair / Recovery) covers from the moment the outage starts to the moment service is restored, including the time it took your monitoring to notice. Some teams track MTTD (detection) and MTTR separately because detection is the hard part.