How long will it take to move that much data? Enter the size and your connection speed — with a realistic efficiency, not the number on the box.
Use your upload speed below. On most connections the two differ a lot, which is why a backup that took days can restore in hours — or the reverse.
Nobody sustains their advertised rate. Protocol overhead, latency and disk speed all take a cut, and millions of small files can push this below half.
1 day 2 hr
That window holds 306 GB at this rate.
Does not fit — needs 1 day 2 hr.
A faster link is only one of three levers. Sending less data (compression, dedup) or raising achievable efficiency (fewer, larger files) often gets there sooner and cheaper.
100 Mbps is 12.5 MB/s at line rate — connections are sold in bits, files are measured in bytes, and the factor of 8 between them is the most common mistake in this calculation.
Pick decimal units (GB, TB) or binary ones (GiB, TiB) — the tool keeps them distinct, because 1 TiB is about 10% larger than 1 TB and that gap alone can swallow a backup window.
Use your UPLOAD speed for a backup and your DOWNLOAD speed for a restore. On most consumer and many business connections these are wildly different, which is why a backup that took two days can restore in two hours.
This is the share of the advertised line rate you actually sustain. 85% is a fair default for large files on a healthy link; drop to 65% on a busy shared connection and to around 40% for millions of small files, where per-file overhead dominates and the link is barely the constraint.
You get the elapsed time plus how much data moves per hour and per day at that rate. The per-day figure is the one to compare against your backup window: if a nightly job cannot finish inside it, the schedule is wrong regardless of how fast the link is.
Connections are sold in megaBITS per second; files are measured in megaBYTES. Forgetting the factor of 8 makes an estimate eight times too optimistic, and it is the single most common error in this calculation.
Nobody sustains their advertised line rate. Protocol overhead, latency, disk read speed and per-file overhead all take a cut, so the tool asks what you actually achieve instead of quietly assuming 100%.
GB and GiB are different quantities and the difference compounds at scale: 10 TiB is about 1.1 TB more data than 10 TB. Both are offered so you can match whatever your tooling reports.
Throughput per hour and per day is shown alongside the total, so you can answer the real question — does this finish overnight — rather than converting seconds in your head.
Restore time is the same arithmetic on the download side. Worth doing deliberately, because a recovery time objective assumed from upload speed is usually wrong in the optimistic direction.
No upload, no account, no logging. Your data volumes and link speeds stay on the page.
The first full backup is where this bites hardest. Incrementals after it are small and finish easily, but seeding a repository means moving everything once — and on a modest upload link that can take weeks rather than the overnight run people assume. Knowing that up front changes the plan: stagger the seed, ship a drive, or start with the data that matters most.
Restores are the other half, and the more important one. A recovery time objective is a promise about how long a restore takes, and the transfer is often the largest part of it. If 5 TB has to come back over a 100 Mbps link, the arithmetic says more than five days at a realistic efficiency — so an RTO of one day is not achievable that way regardless of intent. Better to discover that during planning than during an incident.
Backup windows are a scheduling constraint disguised as a bandwidth question. If a nightly job has eight hours and the link moves 306 GB in that time, then a nightly change set larger than that will never finish, and each run starts further behind. The per-day throughput figure exists to make that visible.
Finally, this is a useful sanity check on any transfer estimate. If a vendor tool or a progress bar claims a duration that contradicts the arithmetic by a wide margin, one of the assumptions — the units, the direction of the link, or the achievable share of line rate — is wrong.
A 100 Mbps upload link, an eight-hour overnight window, and a nightly change set of about 400 GB. The question is not how fast the link is, it is whether the job can finish before people arrive.
It does not fit — the window holds about 306 GB and the job needs 400 GB, so every night finishes late and the backlog grows. The fix is not a faster link alone: reducing the change set with better compression or dedup, or splitting the job across two windows, gets there without new bandwidth.
Elapsed time at 85% of the advertised line rate, which is a realistic figure for large files on a healthy link. Read down for your data volume, across for your connection.
| Data | 20 Mbps | 100 Mbps | 500 Mbps | 1 Gbps |
|---|---|---|---|---|
| 100 GB | 13 hr 4 min | 2 hr 37 min | 31 min | 16 min |
| 500 GB | 2 days 17 hr | 13 hr 4 min | 2 hr 37 min | 1 hr 18 min |
| 1 TB | 5 days 11 hr | 1 day 2 hr | 5 hr 14 min | 2 hr 37 min |
| 5 TB | 27 days 6 hr | 5 days 11 hr | 1 day 2 hr | 13 hr 4 min |
| 10 TB | 54 days 11 hr | 10 days 21 hr | 2 days 4 hr | 1 day 2 hr |
Generated with this calculator at 85% efficiency. Lower it for shared links or many small files and every figure grows proportionally — at 40%, the 1 TB over 100 Mbps row becomes more than two days.
At 100 Mbps and a realistic 85% efficiency, about 1 day and 2 hours. On a 20 Mbps upload link it is closer to five and a half days, and on gigabit about two and a half hours. The table above covers the common combinations — and note the answer changes with your UPLOAD speed, which on many connections is a fraction of the download speed you were sold.
Usually one of four things. Efficiency is set too high for the workload — millions of small files can drop effective throughput below half of line rate because per-file overhead dominates. The link is shared and you are not getting all of it. The source disk cannot read as fast as the network can send. Or the bottleneck is at the far end rather than yours. Try lowering the efficiency figure to whatever you actually observed and use that for future planning.
A factor of eight. Mbps is megabits per second, MB/s is megabytes per second, and there are 8 bits in a byte — so a 100 Mbps connection moves at most 12.5 MB/s. Internet connections are advertised in bits because the number looks bigger; file sizes are in bytes. Mixing them up is the most common reason an estimate is wildly optimistic.
Upload for a backup, download for a restore. This matters more than it sounds: many connections are heavily asymmetric, with upload a small fraction of download. Sizing a backup window with the download figure will understate it badly — and, worse, sizing a recovery time objective with the upload figure will overstate how long recovery takes and may push you into buying something you did not need.
No. 1 TB is 1,000,000,000,000 bytes; 1 TiB is 1,099,511,627,776 — about 10% more. Storage is usually sold in decimal units while operating systems often report binary ones, which is why a "1 TB" drive shows as roughly 931 GiB. Both are supported here so you can enter whatever figure you actually have.
The arithmetic offers three levers, and bandwidth is only one. Reduce what you send — compression and deduplication cut the bytes before they hit the wire. Raise achievable efficiency, which for many small files often means archiving them into fewer larger ones. Or move the seed out of band entirely by shipping physical media, then let incrementals maintain it. Increasing the link speed is usually the slowest and most expensive of the three to arrange.
Work out how much data you are moving in the first place, from your retention policy.
Convert between GB and GiB, and see why a drive shows less than the box claimed.
Put a figure on what the restore time you just calculated actually costs.