Three durations, and only one of them repeats
The seed is the first complete copy, and it is the number that stops projects. Two terabytes of source at a compression ratio of 1.4 is about 1.43 terabytes on the wire, and a 40 Mbps upstream that the backup gets 80 percent of is 4 MB/s, so the seed runs for roughly 99 hours of transfer. If it only runs during an eight hour overnight window, that is somewhere north of twelve nights before the first copy exists.
The nightly run afterwards is a completely different size. Two percent of two terabytes is 40 GB of source, about 29 GB compressed, which is under two hours at the same rate. That is the number that has to fit in the window, every night, forever, and it is the one worth designing around.
The third number is the restore, and it is the only one that has ever mattered to anybody. It runs the other way down the link. On a residential connection where the download is several times the upload, a restore is much quicker than the seed was, which surprises people who assume symmetry. On a connection where the two are equal, or against a destination that limits how fast you can pull data back out, that comfortable relationship disappears.
The change rate is the field to measure, not guess
Everything downstream of the nightly figure depends on how much of the data actually changes, and intuition about this is poor in both directions. A photograph and video archive is nearly inert: files arrive and are never touched again, so the daily change is almost entirely new material rather than modified material. A working set of documents behaves similarly. Virtual machine disk images, databases and mail stores are the other extreme, because a small logical change can rewrite a disproportionate share of the underlying file, and a defragmentation or a compaction pass can rewrite the whole thing in one night.
Your backup software already knows the answer. The size of the last several incremental runs, divided by the size of the protected set, is the measurement, and it costs nothing to look up. Use a week of runs rather than one, because the day somebody imports a large project is not representative and neither is a quiet Sunday.
Compression ratio is a measurement too
The ratio field asks how many bytes of source fit into one byte at the destination, and the honest answer varies more than any other input here. Text, code, logs, database dumps and virtual machine images compress well. Photographs, video, audio and anything already in a compressed container are close to incompressible, and a claimed high ratio applied to a media library is a fiction that will show up as a seed running for twice as long as planned.
Deduplication is the other half of that field and behaves differently: it pays off enormously when many machines hold the same operating system files, and it does almost nothing for a single machine full of unique material. Both effects land in the same number here because both have the same consequence, which is fewer bytes crossing the link.
What overruns look like from the outside
A job that does not fit its window rarely announces itself. It keeps running into the morning, saturating the same upstream that video calls and everything else in the house need, and the report that arrives is that the internet is slow rather than that the backup is late. The household bandwidth calculator shows what that collision looks like from the other side, and the short version is that a saturated upstream slows downloads too, because the acknowledgements they depend on cannot get out.
| Lever | What it changes | What it costs |
|---|---|---|
| Exclude data that does not need protecting | Both the seed and the nightly run | Deciding what is genuinely disposable, which takes a conversation |
| Rate limit the job | Makes it longer on purpose | Window headroom, in exchange for the link staying usable |
| Seed to a local device and ship it | Removes the seed from the link entirely | Handling, and a device that has to get there intact |
| Buy upstream | Everything, proportionally | Money, where the connection type allows it at all |
| Improve the compression ratio | Bytes on the wire | Processing time on the source machine |
The restore is the part to rehearse
Restoring one file is a quick operation and tells you the pipe works. Restoring everything is a different exercise, and the difference is not only size. Many small files restore far more slowly than their byte count suggests because each one costs a round trip and a filesystem operation, which is why the restore overhead multiplier exists on this page rather than an assumption of a straight transfer. Decryption, unpacking and verification all sit on top.
The statement worth being blunt about: an untested restore is not a backup, in the plain sense that nothing about it has been shown to work. That is a remark about evidence rather than advice. If the protected set is an array, note also that redundancy and backup are unrelated protections against unrelated failures, which the storage array capacity calculator works through, and what a copy has to satisfy to count as offsite is in the cloud backup guide. The space cost of keeping many restore points, rather than the time cost of making them, is on the backup retention calculator.
Questions people ask
Why does the first backup take days and the second one minutes?
Because they move completely different amounts of data. The first run copies everything you own; every run after it copies only what changed since the previous one. If two percent of the data changes daily, the second run is a fiftieth the size of the first, and the ratio is even more lopsided on an archive that mostly sits still. This is also why an interrupted seed hurts so much and a missed incremental barely does. Most software resumes a seed where it left off, but the total volume does not shrink, so a seed that keeps getting interrupted stretches out for weeks.
How do I find my real daily change rate?
Look at the size of your own recent incremental runs. Nearly every backup tool reports the transferred or stored size of each job, so take the last seven and divide the average by the total protected size. That single measurement replaces every rule of thumb, and it is the input this page is most sensitive to. Do it again after any large change in what you keep, because adding a virtual machine or a database to the protected set can move a household figure from under one percent to well into double digits.
Should I rate limit the backup or let it run flat out?
It depends entirely on whether the window has room. A job with hours of slack can be limited to a fraction of the link and still finish, and the household stops noticing it exists. A job already using most of its window cannot be limited without overrunning. The calculator shows the change rate that would exactly fill the window, so the gap between that figure and your measured change rate is the room you have to slow the job down deliberately. Where the connection is shared with video calls, deliberate limiting is usually worth more than finishing early.
Is a local backup drive better than an offsite one?
They fail differently, which is the entire point of having more than one. A directly attached drive moves data at a speed no residential link can approach, so seeds and restores are fast, and it sits in the same building as the thing it is protecting, so a fire, a flood, a theft or ransomware that reaches mapped drives takes both. An offsite copy survives all of those and is slow. The reason the usual advice lands on keeping both is that neither one covers what the other does, not because more copies is a virtue in itself.
What makes a restore slower than the same amount of data going out?
Several things stack. The transfer itself may be limited differently in that direction, either by the connection or by the destination service. Data has to be decrypted and unpacked rather than merely written. Many small files each cost a filesystem operation and a round trip, so a set of a million small documents restores far slower per byte than one large image would. And verification, if you do it and you should, is a second read of everything. The multiplier field exists so you can put your own measured figure in after doing a restore drill once.