Test an RTO against reality: detection, decision and provisioning time plus the restore time your data volume and throughput actually allow.
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.
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 = 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.
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.
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.
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.
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.