Backup planning / the first upload

How long does it take to back up 1 TB?

At 20 Mbps upload, one decimal terabyte needs at least 111 hours—about 4 days and 15 hours. At 80% usable throughput, it becomes almost 139 active hours. Give the job only eight hours each night and the elapsed time stretches to roughly 17 days.

I treat the first cloud backup as a capacity-planning problem. If the initial copy cannot catch up, the daily changes start piling onto a queue that was already behind. The useful estimate therefore needs three numbers: bytes to send, sustained upload throughput, and hours per day the backup is allowed to run.

Calculate your data size, upload speed, and daily window

One terabyte at common upload speeds

One decimal terabyte is 1,000,000,000,000 bytes, or eight trillion bits. Divide those bits by the upload rate in bits per second. The theoretical column below assumes every advertised bit is available to the backup without interruption. The 80% column is an example allowance for overhead and other traffic, not a promise that every connection achieves 80%.

Those times are the network transfer only. File discovery, hashing, compression, encryption, provider-side processing, retries, and slow source storage can make the real job longer. Compression and deduplication can also reduce the number of bytes that actually cross the connection.

Mbps is not MB/s

Internet service is normally advertised in megabits per second. File sizes are displayed in bytes. Eight bits make one byte, so 100 Mbps is at most 12.5 MB/s before overhead. Reading 100 Mbps as 100 megabytes per second produces an answer eight times too optimistic.

The unit printed as “TB” can also hide a difference. Decimal TB uses powers of 1,000. Binary TiB uses powers of 1,024. One TiB contains about 1.10 trillion bytes, roughly 10% more than one TB. I choose the unit reported by the storage or backup tool instead of silently treating the labels as interchangeable.

An overnight-only backup spends most of the day waiting

Limiting a backup to eight hours a night does not simply divide active hours by eight and call the result elapsed time. The stopped periods between windows belong in the answer.

At 20 Mbps and 80% usable throughput, the 1 TB example needs 138.9 active hours. Seventeen complete eight-hour windows move 136 hours of data. The final 2.9 hours run on night eighteen. Between those windows are seventeen 16-hour gaps, so the elapsed time is about 410.9 hours: a little over 17 days.

The calculator includes those waiting periods. It assumes one window at the same time each day and that the transfer begins at the start of the first window.

I use sustained throughput, not the best speed test

A browser speed test answers what the connection did for a short test against a nearby server. A multi-day encrypted backup follows a different path and competes with everything else in the house. I start with the speed test when nothing better exists, then replace it with the transfer rate reported by the actual backup after it has run long enough to settle.

If the software reports effective throughput in MB/s, I convert it to Mbps by multiplying by eight. If that number already reflects the real transfer, I use 100% as the calculator’s usable share; deducting overhead again would count the same loss twice.

The source can be slower than the internet

Hundreds of thousands of tiny files can spend more time being opened, inspected, and encrypted than transferred. A busy hard drive, a slow network share, antivirus scanning, or a small backup appliance can become the limit even when fiber upload is available.

I check the observed network rate during the job. If a 500 Mbps connection carries only 40 Mbps while the source disk is busy, entering 500 Mbps produces fiction. The bottleneck that is visible during the transfer is the number that belongs in the plan.

The first backup is not the steady state

After the initial terabyte lands, the system still has to keep up with new and changed data. I estimate a representative day’s changes separately. If 100 GB changes every day, that is not a rounding error on a slow uplink.

At 20 Mbps and 80% usable throughput, 100 GB takes about 13.9 active hours. An eight-hour nightly window would add work faster than it can be sent. The first backup could finish and the queue could immediately start growing again.

The steady-state test is simple:

daily bytes added must be less than daily bytes the upload window can send

Upload time does not answer restore time

A successful off-site copy is only half the design. Restore speed may use a faster download connection, but provider retrieval limits, archive delays, egress charges, destination storage, and the number of files can dominate. A service that can ingest the first backup in two days may still take longer to prepare an archive for recovery.

I keep the restore question separate because pretending it is the upload calculation can hide the most important limitation. The practical test is a real restore of enough data to expose authentication, permissions, file metadata, and throughput problems before an emergency does it.

My planning checklist

1. Measure the bytes that will actually be selected, not merely total disk capacity.
2. Use upload speed and convert bits and bytes correctly.
3. Replace a short speed-test result with observed backup throughput when available.
4. Include the hours when the schedule prevents uploading.
5. Check whether daily changes fit inside the recurring window.
6. Confirm that interruptions resume instead of restarting large files.
7. Test a restore and record the result separately.

Sources and disclosure

Unit definitions follow the National Institute of Standards and Technology’s binary-prefix guidance. The transfer and schedule examples are direct calculations from the labeled inputs. They are not performance claims for a backup provider.

Disclosure: This page contains no affiliate links and does not recommend a backup vendor. If a commissioned storage or networking link is added later, I will label it beside the link.