Disaster Recovery RTO Calculator

Test an RTO against reality: detection, decision and provisioning time plus the restore time your data volume and throughput actually allow.

Inputs

Data to restoreGB

Sustained restore throughput per streamMbps

Parallel restore streamsstreams

Time to detect and declare the incidentminutes

Time to authorise invocationminutes

Time to provision the recovery targetminutes

Time to validate and hand back the serviceminutes

Target RTOhours

Achievable RTO

3.83hours

Data Restore Time

100.0minutes

Detection, Decision and Setup Time

130minutes

Margin Against the Target

10minutes

Throughput Needed to Hit the Target

2,909Mbps

Additional Throughput Required

0Mbps

Share of the RTO Spent Not Restoring

56.5%

Target Verdict

Target met with 10 minute(s) of margin

Binding Constraint

Human and provisioning time — automate detection, pre-authorise the invocation decision and pre-build the recovery target

Step by step

Values used
Data to restore = 2,400 GB; Sustained restore throughput per stream = 800 Mbps; Parallel restore streams = 4 streams; Time to detect and declare the incident = 15 minutes; Time to authorise invocation = 30 minutes; Time to provision the recovery target = 45 minutes; Time to validate and hand back the service = 40 minutes; Target RTO = 4 hours
Disaster Recovery RTO
Achievable RTO = detection + decision + provisioning + validation + restore time, where restore time = data volume × 8 × 1000 ÷ (throughput per stream × streams) ÷ 60 minutes.
Required throughput
Throughput required to hit the target = data volume in megabits ÷ (target RTO − fixed overhead), which is zero-capacity when the overhead alone exceeds the target.
Achievable RTO
= 3.83 hours
Data Restore Time
= 100.0 minutes
Detection, Decision and Setup Time
= 130 minutes
Margin Against the Target
= 10 minutes
Throughput Needed to Hit the Target
= 2,909 Mbps
Additional Throughput Required
= 0 Mbps

How it works

An RTO is the sum of a fixed human component and a variable data component, and most published RTOs quietly assume the human part is zero. Detection, authorisation and validation typically consume more of a four-hour window than the restore itself, which is why the calculator reports the overhead share and names the binding constraint rather than just totalling the minutes. An RTO that has never been checked against restore throughput is a number in a policy document, and the gap only becomes visible during the incident. This is an engineering estimate from your own figures, not a tested recovery result — only a real failover test proves an RTO.

Formulas

Disaster Recovery RTO

Achievable RTO = detection + decision + provisioning + validation + restore time, where restore time = data volume × 8 × 1000 ÷ (throughput per stream × streams) ÷ 60 minutes.

× 8 × 1000: Gigabytes to gigabits to megabits, so the volume matches a Mbps throughput
streams: Parallel restore streams, which multiply usable throughput until the target storage saturates
overheadMinutes: The fixed human and provisioning time that no bandwidth reduces

Required throughput

Throughput required to hit the target = data volume in megabits ÷ (target RTO − fixed overhead), which is zero-capacity when the overhead alone exceeds the target.

restoreBudget: Minutes left for data movement after the fixed overhead
requiredMbps: Aggregate throughput needed across all streams

Frequently Asked Questions

How is Disaster Recovery RTO calculated?

Achievable RTO = detection + decision + provisioning + validation + restore time, where restore time = data volume × 8 × 1000 ÷ (throughput per stream × streams) ÷ 60 minutes. An RTO is the sum of a fixed human component and a variable data component, and most published RTOs quietly assume the human part is zero. Detection, authorisation and validation typically consume more of a four-hour window than the restore itself, which is why the calculator reports the overhead share and names the binding constraint rather than just totalling the minutes.

Why does Disaster Recovery RTO matter?

An RTO that has never been checked against restore throughput is a number in a policy document, and the gap only becomes visible during the incident. This is an engineering estimate from your own figures, not a tested recovery result — only a real failover test proves an RTO.

What values do I need to enter?

This calculator takes 8 inputs: Data to restore, Sustained restore throughput per stream, Parallel restore streams, Time to detect and declare the incident, Time to authorise invocation, Time to provision the recovery target, Time to validate and hand back the service, Target RTO. 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 is my RTO impossible even with fast storage?

Because bandwidth only compresses the restore component. If detection takes fifteen minutes, the on-call decision thirty, provisioning forty-five and validation forty, you have consumed over two hours of a four-hour RTO before a single byte moves. Automating detection and pre-authorising invocation usually buys more than a storage upgrade.

Do parallel streams really multiply throughput?

Up to a point. They help until you saturate the target storage, the network path or the restore engine's own concurrency limits, and beyond that adding streams increases contention. Measure your actual aggregate rate during a test and enter that rather than a vendor figure.

You might also need

Disaster Recovery RPO Calculator Business Continuity Calculator Business Impact Analysis Calculator