Start with a deadline
“We have a backup” does not answer “When can we work again?” Start with the latest acceptable recovery time, then split the work into stages: access the backup, prepare a destination, retrieve the data, restore the application and check the result. A transfer estimate covers only one part.
The amount of data you can afford to lose and the amount of time you can afford to be offline are separate decisions. Frequent backups may reduce the data-loss window without making a multi-terabyte restore any faster.
Translate the connection into time
At a sustained 100 Mbps, transferring 2 decimal TB takes about 44.4 hours in the idealized calculation. Assume only 70% of that rate is usable and the estimate rises to about 63.5 hours. Add two hours for setup and validation and the modeled total is about 65.5 hours, or 2.73 days.
Those numbers are calculations, not a promise about a provider. The effective path might be limited by Wi-Fi, competing traffic, storage writes, decryption, small files or request limits. A faster internet subscription helps only when the WAN link is the bottleneck.
Estimate your restore window ↗
Run a small, representative rehearsal
Restore into a separate destination so the rehearsal does not overwrite working data. Include both large files and the small-file mix that matters to your application. Time the full process from locating credentials to opening the recovered files. Record the data size, observed throughput and any manual steps.
If the restore needs a database or another stateful application, check the backup method's consistency requirements. A folder of copied files may not be a usable application backup. Use the documentation for your chosen software to establish the restore procedure.
Reduce what has to happen on the critical path
If the estimate misses the deadline, identify the smallest dataset needed to resume essential work. A staged recovery can bring the important service back before an archive finishes downloading. A separate local copy may also shorten recovery when the local incident has not affected it; off-site protection remains relevant for failures that affect the whole location.
Keep a short recovery record containing the backup location, credential recovery path, encryption-key location, application procedure, destination requirements and the date of the last successful test. Store the record somewhere accessible when the system you are recovering is unavailable.
Sources & scope
Reference check: 29 October 2026. Examples are our calculations, not measured provider benchmarks.