Skip to content
ENExplore Calculators

Recovery Time Calculator

Build an end-to-end RTO from detection, decision, mobilisation, restore throughput, validation and cutover for a tiered estate.

About Recovery Time Calculator

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.

Formula

Recovery Time

RTO = detection + declaration + mobilisation + (dataVolume ÷ restoreThroughput) + (systems × configMinutes ÷ parallelTeams) + validation.

detection
Time from compromise or failure to someone knowing
declaration
Time to authorise invoking the recovery plan
configMinutes
Hands-on configuration per recovered system
validation
Application testing and traffic cutover

Worked example

With the default values below, Recovery Time Calculator returns Achievable RTO of 11.67. Change any input above and every figure here is recalculated in your browser.

Inputs used

Detection timeaccepts 0–720 hours
2 hours
Declaration and decision timeaccepts 0–168 hours
1.5 hours
Team mobilisationaccepts 0–168 hours
1 hours
Tier-1 data to recoveraccepts 1–10,000,000 GB
8,000 GB
Aggregate restore throughputaccepts 1–100,000 MB/s
1,200 MB/s
Systems to recover in tier 1accepts 1–10,000 systems
25 systems
Configuration work per systemaccepts 0–1,440 minutes
20 minutes
Teams working in parallelaccepts 1–200 teams
3 teams
Application validation and cutoveraccepts 0–336 hours
2.5 hours

Results

Achievable RTO
11.67 hours
Time Before Restore Starts
4.50 hours
Data Movement Time
1.90 hours
System Configuration Time
2.78 hours
Share Spent Before Recovery Begins
38.5%
Largest Phase
Detection and decision
Fastest Improvement
Pre-authorise the disaster declaration — the delay is human, not technical

Step by step

  1. 1Values used
  2. 2Recovery Time
  3. 3Achievable RTO= 11.67 hours
  4. 4Time Before Restore Starts= 4.50 hours
  5. 5Data Movement Time= 1.90 hours
  6. 6System Configuration Time= 2.78 hours
  7. 7Share Spent Before Recovery Begins= 38.5
  8. 8Largest Phase= Detection and decision

Assumptions and limits

  • The result is derived only from the 9 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is Recovery Time calculated?

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.

Why does Recovery Time matter?

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.

What values do I need to enter?

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.

Why include detection time in the RTO?

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.

How does this differ from the backup recovery calculator?

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.

Related Calculators

Recovery Time Calculator – Calculate Achievable RTO