Recovery Time Calculator

RTO = detection + declaration + mobilisation + (dataVolume ÷ restoreThroughput) + (systems × configMinutes ÷ parallelTeams) + validation. An achievable RTO is the sum of six phases, and only one of them is copying data. Detection, the decision to declare a disaster and getting people into a bridge routinely consume the first several hours; per-system configuration scales down with parallel teams but never to zero; and validation before cutover is what stops you failing over to a broken environment.

Naming the largest phase tells you where to spend money — replication does nothing for an RTO dominated by a four-hour argument about whether to declare a disaster.

This calculator takes 9 inputs: Detection time, Declaration and decision time, Team mobilisation, Tier-1 data to recover, Aggregate restore throughput, Systems to recover in tier 1, Configuration work per system, Teams working in parallel, Application validation and cutover. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Because the business experiences the outage from the moment service degrades, not from the moment IT starts restoring. Excluding detection is how a plan claims a four-hour RTO for an incident that took nine hours to resolve.

That one sizes the restore itself — chain length, streams, verification. This one wraps the whole incident: the human phases either side, per-system rebuild work and cutover. Use both: the restore figure feeds the data-movement phase here.