Backup Restore Time Calculator

{{ result.statusText }} {{ result.transferBadge }} {{ result.rtoBadge }} {{ result.requiredBadge }} {{ result.sizeBadge }}

Logical backup size:

Enter the source restore size, then choose the unit used by your backup catalog.

Compression ratio:

Use 1.0 when the catalog reports already-compressed transferred size.

Restore throughput per stream:

Use backup logs, restore tests, or storage counters for the sustained value.

Mbps

Parallel streams:

Use whole streams; reduce this when target I/O or backup appliance slots are constrained.

streams

Catalog and mount time:

Include operator start steps that occur before bulk data movement.

min

Validation time:

Add the required verification time before the service can be declared restored.

min

RTO target:

Set 0 to skip RTO fit checks.

Workload name:

Optional label for copied tables, JSON, and DOCX exports.

Archive retrieval delay:

Leave 0 for warm/local backups.

Staging overhead:

Use 0 for direct restores; add overhead for rehydration, unpacking, or cross-tier copy.

Cutover allowance:

Leave 0 if validation already includes cutover.

min

Phase	Duration	Elapsed	Detail	Copy
{{ row.phase }}	{{ row.duration }}	{{ row.elapsed }}	{{ row.detail }}

Checkpoint	Elapsed	Status	Action	Copy
{{ row.checkpoint }}	{{ row.elapsed }}	{{ row.status }}	{{ row.action }}

Scenario	Aggregate throughput	Transfer time	Total restore	RTO status	Copy
{{ row.scenario }}	{{ row.aggregate }}	{{ row.transfer }}	{{ row.total }}	{{ row.status }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Restore timing is measured by the moment a service is usable again, not by the moment data starts moving. The outage clock can include choosing the recovery point, waiting for archive media, mounting or provisioning a target, transferring data, rehydrating compressed or deduplicated blocks, validating the application, and making the final handoff.

Recovery Time Objective, or RTO, is the maximum acceptable delay between service interruption and service restoration. It is different from Recovery Point Objective, or RPO, which describes how much data loss is acceptable. A workload can meet its RPO because a recent backup exists and still miss its RTO because the restore path is too slow.

Restore planning terms and why they affect elapsed recovery time
Planning term	What it controls	Common mistake
RTO	The downtime target the recovery process must fit inside.	Choosing a target before checking whether fixed recovery work already consumes it.
RPO	The maximum age of the recovered data point before data loss becomes unacceptable.	Assuming a recent backup also means a fast restore.
Restore throughput	The sustained data movement rate observed during recovery.	Using network line rate instead of tested restore speed.
Fixed recovery time	Work that does not shrink when bulk transfer runs faster, such as validation or approval.	Hiding catalog, archive, validation, or cutover time inside the transfer estimate.

Restore timeline with archive, catalog, transfer, staging, validation, cutover, and an RTO target.

Restore estimates are most useful when the inputs come from recovery drills or backup-job logs. Interface line rate, appliance marketing throughput, and cloud storage class labels do not say how fast a particular workload can be restored under pressure. Target storage write speed, deduplication rehydration, restore-job slots, encryption checks, and operator access can all become the slow part.

Compression and deduplication need careful unit handling. A logical backup size is the protected data size before reduction, while a stored or transferred size may already reflect compression. Mixing those meanings can double-count savings and make a restore appear much faster than it is. Decimal TB and binary TiB also differ enough to matter for multi-terabyte jobs.

A restore-time estimate remains a planning aid, not proof of recoverability. It can show whether a timing model fits the outage target, but it cannot prove that credentials work, backups are intact, dependencies are available, or the application passes business validation after the data lands.

How to Use This Tool:

Model one recovery path at a time. Use the same size definition, unit system, and throughput basis throughout the estimate so the result matches the runbook you intend to test.

Enter Logical backup size and choose the unit shown by the backup catalog: GB, TB, GiB, or TiB.
Set Compression ratio. Use 1.0 when the value you entered is already a stored or transferred size.
Enter tested Restore throughput per stream, then set Parallel streams to the number of whole restore streams that can run together without hitting shared limits.
Add Catalog and mount time and Validation time. These phases are included in the end-to-end restore window, not hidden inside the transfer rate.
Enter an RTO target when you want a pass or risk comparison. Set it to 0 when you only want the restore duration.
Open Advanced for runbook-specific items such as Workload name, Archive retrieval delay, Staging overhead, and Cutover allowance.
Review Restore Phases, RTO Checkpoints, and Throughput Scenarios before sharing the estimate. The phase rows show where time is spent, while the scenario rows show how much faster transfer would change the total.

Interpreting Results:

Restore window is the modeled total elapsed time from the beginning of recovery work through validation and cutover. Read it with the RTO fits or RTO risk cue. The same two-hour restore may be acceptable for a four-hour database objective and unacceptable for a thirty-minute customer-facing service objective.

How to interpret backup restore time result cues
Cue	What it means	What to check next
RTO fits	The modeled restore window is less than or equal to the entered RTO target.	Keep test evidence with the runbook, especially when the spare time is small.
RTO risk	The modeled restore window exceeds the entered RTO target.	Compare the shortfall with the required aggregate rate and the fixed recovery phases.
Fixed phases exceed RTO	Archive, catalog, validation, and cutover time already consume the target.	Shorten the recovery process or change the recovery design before adding bandwidth.
Transfer-bound	The 2x throughput check shows a meaningful reduction when data movement improves.	Test more streams, faster media, pre-staging, or a different recovery location.

Required aggregate rate is the restore throughput needed to fit the target after fixed recovery time is subtracted. When that field says the rate is not attainable from throughput alone, the problem is not only the data path. Archive delay, catalog work, validation, or cutover is already too large for the RTO.

Phase Duration Chart makes fixed-time bottlenecks obvious because nonzero phases remain visible beside transfer. Throughput Sensitivity Curve is better for capacity planning because it compares current throughput with 0.5x, 0.75x, 1.25x, 1.5x, 2x, and 3x scenarios.

Treat warnings as prompts for evidence. Extremely high aggregate throughput should be checked against restore appliance limits, target storage, and network paths. Archive retrieval warnings matter because cold-storage restores can vary with service capacity and queueing.

Technical Details:

The restore model separates variable data movement from fixed recovery work. Variable time depends on transferred bytes and aggregate throughput. Fixed time covers archive retrieval, catalog and mount work, validation, and cutover. Staging or rehydration is modeled as a percentage of transfer time, so it grows with slower transfers and shrinks when sustained throughput improves.

Parallel streams are counted as whole streams and multiply the per-stream rate. This is a planning assumption, not a guarantee that the source, network, restore engine, and target can all scale linearly. Compression ratio reduces transferred bytes only when the entered size is logical size; already-compressed sizes should use a ratio of 1.0.

Formula Core:

The core calculation converts the entered size to bytes, divides by compression ratio, calculates aggregate throughput, then adds the non-transfer phases.

\begin{array}{lcl} B_{transferred} & = & \frac{B_{logical}}{C} \\ R_{aggregate} & = & R_{stream} \times N \\ T_{transfer} & = & \frac{B_{transferred}}{(R_{aggregate} \times 1000000 / 8)} \\ T_{total} & = & T_{archive} + T_{catalog} + T_{transfer} + (T_{transfer} \times S) + T_{validation} + T_{cutover} \end{array}

Here, C is the compression ratio, N is the whole stream count, and S is staging overhead as a decimal. Throughput is entered in megabits per second, so the formula converts megabits to bits and then to bytes.

Restore input boundaries and effects
Quantity	Boundary used	Effect on restore time
Backup size	Negative values are treated as zero after unit conversion.	Larger logical size increases transferred bytes unless compression offsets it.
Compression ratio	Values below 1.0 are raised to 1.0.	Higher values lower transferred bytes only when the size is logical.
Parallel streams	Values are rounded down to whole streams and kept at least 1.	More usable streams raise aggregate Mbps linearly in the model.
Staging overhead	Allowed from 0% to 300%.	Adds extra time as a percentage of bulk transfer duration.
RTO target	Zero disables the fit comparison.	Positive values create margin, shortfall, and required-rate checks.

The required throughput check subtracts fixed phases before sizing the data path. If the remaining budget is positive, staging overhead is folded into the available transfer time. If the remaining budget is zero or negative, no aggregate rate can make the model fit because the fixed phases have already used the outage target.

R_{required} = \frac{B_{transferred} \times 8 \times (1 + S)}{(T_{RTO} - T_{fixed}) \times 1000000}

Displayed durations are rounded for readability, but the comparisons use the underlying seconds. Scenario rows recalculate the same model at different throughput multipliers, so they are comparable as long as the fixed phases and staging percentage still describe the same recovery design.

Limitations and Privacy Notes:

The estimate does not inspect a backup catalog, authenticate to storage, start a restore job, or verify recovered data. Use it to size and explain a restore window, then confirm the result with scheduled recovery tests, application smoke checks, and evidence from the backup platform.

Disaster-time conditions can be worse than routine restore tests. Cloud archive queues, regional service load, damaged credentials, unavailable staff, changed network paths, and dependent systems can add time that is not visible in a normal steady-state throughput measurement.

The calculation runs in the page and does not require uploading restore details. If you copy or share a configured URL, treat the visible values in that link as sensitive because workload names, sizes, and targets may reveal operational information.

Worked Examples:

Production database restore inside target. A 4.5 TiB logical restore with a 1.8 compression ratio transfers about 2.50 TiB. At 2500 Mbps per stream with two streams, aggregate throughput is 5000 Mbps and bulk transfer takes about 1.22 hours. Add 20 minutes of catalog work and 45 minutes of validation, and the restore window is about 2.31 hours. Against a 4-hour RTO, the model leaves about 1.69 hours of spare time.

Archive retrieval that changes the answer. A 12 TiB logical restore with a 2.0 compression ratio transfers about 6.00 TiB. Three 1200 Mbps streams give 3600 Mbps aggregate throughput, so transfer takes about 4.07 hours. Add a 2-hour archive retrieval delay, 30 minutes of catalog work, 20% staging overhead, 60 minutes of validation, and 15 minutes of cutover, and the total is about 8.64 hours. An 8-hour RTO becomes a risk even though the transfer rate looks reasonable.

Transfer-bound shortfall. A 20 TiB logical backup with a 1.2 compression ratio leaves about 16.67 TiB to transfer. Two 800 Mbps streams create 1600 Mbps aggregate throughput, which stretches bulk transfer to a little over one day before fixed phases. A 6-hour RTO cannot be met without a different recovery approach, much faster tested throughput, or pre-staged data.

Fixed phases that throughput cannot solve. A small 1 TiB restore with a 2.0 compression ratio and four 5000 Mbps streams transfers about 512 GiB in only a few minutes. If the plan also has a 2-hour archive wait, 30 minutes of catalog work, and 30 minutes of validation, the restore still takes about 3.06 hours. A 1-hour RTO fails because the fixed work is larger than the target.

FAQ:

What restore throughput should I enter?

Use measured sustained restore throughput per stream from recovery drills, backup logs, or storage counters. Do not use interface speed unless a test proves the full restore path can sustain it.

Should I enter logical size or stored size?

Enter logical size when you also know the logical-to-transferred compression ratio. If the catalog already gives a stored, transferred, or compressed size, enter that size and set compression ratio to 1.0.

Why can parallel streams make the estimate too optimistic?

The model multiplies per-stream throughput by whole streams. Real restores scale that way only when the source, restore appliance, network, and target storage can sustain all streams at once.

What happens when RTO target is 0?

The pass or risk comparison is skipped. The restore window, phase rows, throughput scenarios, charts, and JSON output still update.

Can this prove my backup is recoverable?

No. A timing model cannot replace a restore test. Use the estimate to plan the target and compare scenarios, then verify recovery with real restores, validation checks, and documented evidence.

Glossary:

Recovery Time Objective: The maximum downtime a workload can tolerate before the outage becomes unacceptable.
Recovery Point Objective: The maximum age of the recovered data point before data loss becomes unacceptable.
Logical backup size: The protected data size before compression, deduplication, or transfer reduction is applied.
Compression ratio: The relationship between logical bytes and bytes that must be read or transferred during restore.
Aggregate throughput: The combined restore rate after per-stream throughput is multiplied by usable parallel streams.
Staging overhead: Extra recovery work modeled as a percentage of transfer time, such as rehydration, unpacking, or temporary copying.
Cutover allowance: Final handoff time for service restart, endpoint changes, DNS work, approval, or user-facing release after validation.

References:

Contingency Planning Guide for Federal Information Systems, NIST Special Publication 800-34 Rev. 1.
Define recovery objectives for downtime and data loss, AWS Well-Architected Framework.
Perform periodic recovery of the data to verify backup integrity and processes, AWS Well-Architected Framework.
Restore testing, AWS Backup User Guide.
How to restore a PostgreSQL database backup, Simplified Guide.
How to restore Elasticsearch snapshots, Simplified Guide.