Backup upload time calculator

The direct answer for one terabyte

At 20 Mbps, one decimal terabyte needs about 111 hours at the absolute minimum. Allowing 80% usable throughput raises the active upload time to about 139 hours—five days and 19 hours if it can run continuously. Limit that same job to eight hours per day and it finishes after roughly 17 days and three hours.

That is why I separate advertised speed, sustained usable speed, and the hours the backup is allowed to run. The first number alone makes a large initial backup look much easier than it is.

How the schedule works

Minimum seconds = bytes × 8 ÷ (Mbps × 1,000,000)
Active upload time = minimum time ÷ usable fraction
Elapsed time = active time + the closed hours between daily upload windows

The calculator assumes one upload window at the same time every day and that the transfer starts at the beginning of the first window. If a job needs 12 active hours and has eight hours available each day, it takes 28 elapsed hours: eight uploading, 16 waiting, then four uploading. It does not add another closed period after the transfer finishes.

Use upload speed, not the big number on the plan

Internet plans often advertise download speed most prominently. Cloud backup is constrained by upload speed. I start with an observed sustained upload result when I have one. If I only have a speed-test result, the usable-percentage field gives me room for protocol overhead, competing traffic, and the fact that a long transfer rarely holds the best short-test rate forever.

If the speed input already comes from an actual file transfer converted to Mbps, I set usable share to 100%. Deducting an allowance again would count the same slowdown twice.

GB is not GiB, and Mbps is not MB/s

GB and TB are decimal units: one billion and one trillion bytes. GiB and TiB use powers of two. A byte contains eight bits, so 100 Mbps is at most 12.5 MB/s before overhead. I use the unit reported by the source of the data-size measurement instead of silently treating the labels as interchangeable.

A backup that cannot catch up is not a schedule

The initial upload is only half the planning problem. I run the calculator again with a representative day of changed data. If each day creates more active upload work than the daily window can clear, the backlog grows forever even after the first backup is seeded.

File scanning, many small files, local disk speed, encryption, provider throttles, connection interruptions, and other household traffic can all make a real backup slower. Compression and deduplication can reduce the bytes sent. A single total-size field cannot predict those effects, so I treat the result as a planning estimate rather than a completion promise.

Upload time is not restore time

A backup can finish uploading and still be a poor recovery plan. Restore speed may face a different internet limit, provider-side preparation, download caps, disk write speed, or the time needed to reconstruct many small files. I keep at least one restore test separate from the upload estimate.

If the first upload is too long, the useful options are to reduce the data set, increase sustained upload capacity, allow a larger daily window, or use a provider with a physical seeding path. Guessing a more optimistic efficiency percentage does not change the connection.

See the full one-terabyte comparison and restore boundary.

Sources and privacy

Unit definitions come from NIST’s binary-prefix reference. Backup-timing context comes from Backblaze’s backup and restoration guidance. The window scheduling and examples are my arithmetic. The calculation stays in the browser; no filenames or files are uploaded to this site. Methods and corrections.