Industry: Telecommunications and IT Product: ModelRisk Application: Data Recovery Optimization under Uncertainty
The contractual recovery-time objective on a major enterprise managed-services contract is RTO = 4 hours for tier-1 systems. The deterministic plan — sum the median backup-fetch, the median restore, the median validate — comes to 2.4 hours and looks comfortable. The simulation says the mean recovery time is 204 minutes (already past the 4-hour line), the P90 is 286 minutes (~4.8 hours), the P99 is 408 minutes (~6.8 hours), and there is a 25% chance a tier-1 restore breaches the 4-hour RTO. Recovery time is a sum of right-skewed components; the median is not the answer.
A managed-services provider running disaster-recovery for ~300 enterprise customers rebuilt its DR forecasting in ModelRisk. The model produces this full distribution of end-to-end recovery time and a parallel data-loss (RPO) distribution — the two metrics that govern every DR contract.
End-to-end recovery is a serial pipeline. The total is the sum, but the shape of the total is dominated by the heavy-tailed components.
Total RTO is the sum, with the backup-fallback and re-validation events introducing correlated jumps into the right tail.
The legacy plan reported a median recovery of ~140 minutes and concluded the 4-hour RTO was a "two-hour buffer". The simulation, charted above, tells the operational reality:
A 1-in-4 restore overshooting the RTO is not a "buffer" — it is a recurring SLA breach the deterministic plan literally cannot show, because the deterministic plan is summing medians of right-skewed distributions and getting a number that has no probabilistic interpretation at all.
Sensitivity on the P90 RTO ranks the four stages by tail leverage — a very different ordering than ranking by mean contribution.
System-restore upper-bound dominates: shifting the triangular upper bound from 240 → 180 minutes (e.g. by adding pre-staged warm-spare configurations) moves P90 by ~30 minutes against a baseline P90 of 286 minutes. Data-fetch σ is second — and is exactly what a 10 Gbps WAN upgrade addresses. Validation re-run probability is third. Backup-integrity success rate is fourth: high mean reliability already, but a Beta(95, 2) is not the same as a Beta(99, 1), and the difference is mostly hidden in routine reporting.
Three architectures were simulated against the same workload:
The active-active step-up adds an extra ~$2.8M/yr per customer in compute and replication egress, which only ~30 customers can justify. Pilot-light at ~$640k/yr/customer is the dominant choice for tier-1 contracts: it clears the 4-hour SLA in essentially every simulated restore without doubling cloud spend.
RPO (data loss) is a separate distribution governed by the backup cadence. With hourly snapshots, RPO ≈ Uniform(0, 60) min on the time-since-last-snapshot — but real-world snapshot success introduces a heavier tail when consecutive snapshots fail.
Mean RPO is ~31 min; P95 RPO is 58 min; the rare consecutive-failure tail pushes P99 RPO to 91 min. For contracts with a 60-min RPO clause, the simulation surfaced a previously invisible 2% probability of breach that the deterministic "we take hourly snapshots" claim concealed.
The recovery plan's median is not the recovery plan's answer. The answer is the full RTO distribution against the SLA threshold — and Monte Carlo is what turns four stage-level distributions into one end-to-end number the DR team and the customer can both sign.