Cloud Backup Time Estimator
Work out how long your first cloud backup will actually take, factoring in the bits providers like Backblaze and iDrive don't always spell out: protocol overhead, the realistic 70-80% utilisation of your advertised upload speed, and the option to only run overnight.
Explain like I'm 5 (what even is this calculator?)
Tell it how much data you want to back up and how fast your upload is. It tells you, honestly, how many days, hours and minutes the first run will take. The first cloud backup is the slow one, after that the client only ships changes and you stop noticing it.
Estimate the first backup
Fill in the form and press the button to see how long the first backup will take.
Continuous upload:
Overnight-only (8pm to 8am):
Prove it
The maths, end to end, so you can audit it.
10% protocol overhead is a round figure for TLS plus the provider's own chunking and metadata. The 70-100% efficiency slider reflects the gap between advertised line speed and what sustained uploads actually achieve, which Backblaze, iDrive and Carbonite all document in their throughput notes.
Save this calculator: press Ctrl + D to bookmark it in your browser.
Upload too slow for the timeline you need?
Compare broadband packages with faster upload speeds. Full fibre (FTTP) typically gives you symmetric or near-symmetric upload, which can shave days off a multi-terabyte first backup.
Compare broadband deals at broadband.co.ukWhy the first cloud backup feels endless
Cloud backup providers like Backblaze, iDrive and Carbonite are very good at the steady-state job: once they have a copy of everything, they only ship the bits that changed since the last run. Most users never notice them after the first week. The first week is the catch. The seed-upload, where the client has to push every photo, document, video and project file you have ever cared about, is the slow part. On a 50 Mbps upload line, half a terabyte at a realistic 80% efficiency takes around 28 hours of continuous upload. A full terabyte takes nearly two and a half days. Five terabytes runs into a fortnight. None of that is the provider's fault. It is your line.
Why the realistic figure beats the line speed figure
Run a speed test, get 50 Mbps up, divide bits by bits, get a clean answer. That answer is wrong by 20-30% in practice for backups specifically. Sustained uploads have to share the line with everything else the household is doing, deal with TCP backoff when the network drops a packet, sit behind Wi-Fi if you are not wired in, and respect any throttling the provider applies at busy times. Backblaze talks openly about thread counts, ISP rate-limits during work hours, and the gap between burst and sustained throughput. iDrive's documentation says the same thing in different words. The realistic figure for sustained backup upload is 70-80% of advertised, sometimes lower. This calculator lets you pick the assumption you trust and shows the working.
What 10% protocol overhead is for
Every byte of your data is wrapped in TLS for encryption, chunked into manageable blocks, tagged with metadata and indexed at the provider. None of that wrapping is free. Across the major backup providers, the realistic overhead lands around 10%, sometimes a little less for very large files where the per-chunk metadata is amortised, sometimes a little more for many tiny files. The calculator uses 10% as a flat figure, which is honest enough for planning purposes and a long way better than ignoring it altogether.
When to switch on overnight-only
If anyone in the house works from home, runs video calls, or just cares about Netflix not buffering, a backup hammering the line during the day is going to cause friction. Most providers let you schedule the backup window or throttle hard during work hours. The calculator's overnight-only toggle assumes the backup client gets the full line from 8pm to 8am and nothing during the day, so the wall-clock time doubles. In practice that is the right trade for households on slower upload, and worth the longer total because the connection stays usable.
Common mistakes when estimating
- Using the download number. Backups are upload-bound. On standard FTTC, upload is much lower than download. Always plug in the upload figure.
- Assuming 100% efficiency. A clean wired link to a fast server in lab conditions might briefly hit advertised. Real backups, over hours, do not.
- Forgetting the overhead. 10% sounds small until you stretch it across a fortnight. It is the difference between finishing on a Friday and finishing on a Sunday.
- Forgetting deduplication and exclusions. The figure assumes you really do back up the data you typed in. Most providers exclude system files and cache directories by default, which can shave a meaningful slice off, especially on Macs and Windows machines with large local caches.
If the answer says "weeks", consider seed-loading
Both Backblaze and iDrive offer a way to skip the seed-upload entirely. iDrive Express ships a USB drive to your door, you copy your data onto it, and post it back. Backblaze has historically offered a similar Restore by Mail service for downloads and previously had a Fireball seed device. If the calculator tells you the first backup will take a fortnight, a posted drive is usually the better answer. Carbonite's pricing model treats heavy seeding differently, so check their current options before committing.
Related calculators
The seed upload is one big transfer. These cover the rest of the line's workload.
Frequently asked questions
Why does an initial cloud backup take so long?
Most home and small-office connections have far less upload than download. A 500 Mbps download line might only push 50 Mbps up, and that ceiling is what backups are bound by. Add in the realistic 70-80% real-world utilisation, plus 10% or so for TLS, chunking and provider metadata, and a few terabytes can take many days even on a fast line. After the first run, subsequent backups only ship the files that changed, so they finish in minutes.
Why use 80% as the default efficiency?
Sustained uploads almost never hit advertised line speed. Wi-Fi attenuation, contention with downloads, the provider's own ingest rate limits, TCP backoff under packet loss, and the slowest hop on the route all chip away at it. Backblaze and iDrive's own documentation talks about throttling, threading and time-of-day effects. 80% is the realistic middle. 70% is more honest for Wi-Fi over a busy household. 100% is what you get on a wired link to an unloaded server in lab conditions, briefly.
What does overnight-only mode actually do?
It assumes the backup client only uploads between 8pm and 8am, leaving work hours alone. That is 12 hours of backup per 24 hours, so wall-clock time doubles compared to a continuous upload. Most providers, including Backblaze and iDrive, let you schedule a backup window or throttle during work hours, which is the same idea.
Does the result include changes after the first backup?
No. This is the initial seed-upload estimate, which is the figure that surprises people. Once it has finished, the client only sends the deltas: a few megabytes a day for most users, occasionally more if you generate large media files.
Should I post a hard drive instead?
If the calculator says days or weeks, it can be cheaper and faster to use a seed-load service. Backblaze offers Restore by Mail. iDrive offers iDrive Express, which couriers a USB drive to you, you copy data onto it, and post it back. For multi-terabyte first backups on slow links, this is usually the right call.