Backup Window Duration Calculator

The house is silent; It’s 3 AM. You look at status monitor with sense of sinking dread: the backup job began at midnight and isn’t even close to completion. Oh well, the data set was larger this week, or maybe connection is slowing down… But the backup window has passed anyway.

At dawn it’ll complete (just as you’re logging into your office), and kids are plugging in their tablets. Why does that sound familiar?

Why Your Backups Take So Long

Because too many people plan backups based off not on arithmetic, but on optimism. They believe their gigabit connection will provide gigabit speed, and that magic will shrink it all down by half; they never works out that way.

That’s where this calculator comes into play. It strips out the guessing and forces you to take each bottleneck in the chain into account, it will crunch the numbers for you (see above).

The problem isn’t as simple as “how big is my data?” because backing up have a series of variables that all depend on one another. How much of your data actualy changed? Is it a full initial seed or an incremental backup?

In most cases, only a fraction of files has changed, which saves a ton of time. However, with an initial seed, you’re pushing the whole thing to the cloud. This requires a completely different approach. This helps you distinguish between two so you don’t plan for a full backup while thinking you’re running an incremental job.

Deduplication/compression is a very strong tool, but with a caveat. It behaves well for some file types and poorly for others. Things like documents, text logs, databases all compresses incredibly well, often dropping down to half their original sizes or even less. On the other hand, media tends not to compress much at all. Music files, JPEG photos, video recordings from security cameras: these are all pre-compressed. Compressing it again only saves a small amount of space (and costs you CPU cycles). The table on the page makes it clear why something like camera footage hardly gets reduced.

Underestimating this will lead you to believe your speeds is going to be great on paper. However, you may find that you overestimated the size savings when nothing actualy happens.

The other gap between theory and reality are network throughput. You may have a ISP that advertises gigabit download/upload, but in the real world there’s overhead for protocols, encryption, and the efficiency of the backup software itself. If your destination drive isn’t able to write at the same rate as the network delivers it, then that gigabit Ethernet cable can turn into a bottleneck very quickly. Both network speed and disk speed matter here. The calculator makes you enter both the network path speed and the target write speed, and will tell you which one of those two are the effective limit. (That’s what most people gets wrong.)

It is easy to forget about the extra time spent on verification. If you can’t recover it, what good is a backup? Reading back a sample file or checking the hashes will ensure that the backup is intact, but it takes time and bandwidth. Depending on how often you need to run it, a quick check may be all you need for a nightly job. But maybe a full read-back are required in case of a one-off migration. How much are you willing to compromise for speed vs certainty?

You should of always add some buffer for a margin. Things happen. The server reboots. The connection drops. Having a 15% margin ensures that even with a few bumps, the job won’t spill out and interrupt your morning routine.

Honor these constraints, and what was once a haphazard guess at when backups occur becomes something solid. The night remains quiet; the data remains intact.