Backup Window Calculator

Work out whether a backup job finishes before the window closes.

What you provide

Dataset size(GB)

Link or target throughput(Mbps)

Data changed since last run(%)

Use 100 for a full backup. Nightly incrementals are usually 1% to 10%.

Link efficiency(%)

Share of the rated speed a backup job actually gets. 70% is a fair working figure.

Backup window(h)

Snapshot and verify overhead(min)

Result

PASS

Finishes in 1.8 h, inside the 8 h window

The job fits inside the window and leaves 6.2 h of headroom. Re-check the figure when the dataset grows by a quarter, since the run time grows with it in a straight line.

Backup window

1.8 hpass

Comfortable
Tight
Overruns

Window: 8 h

Diagnostic telemetry

Data movedFull copy of the dataset: 500.0 GB
Effective throughput70% of the 1000 Mbps link: 700 Mbps
Transfer time: 1.6 h
Snapshot and verify: 10 min
Total run time: 1.8 h
Window used6.2 h spare: 22%

What this cannot tell you

This is arithmetic on the figures you type in. It does not watch your backup job, read your storage or measure your link.
Real runs vary with file count as much as with size. A million small files can take several times longer than one large file of the same total size, because each one costs a separate metadata operation.

Take this with you

How this calculation works

The calculator takes the share of your dataset that has actually changed, divides it by the throughput the link realistically delivers rather than its rated speed, and adds the fixed cost of snapshotting and verification. Backup jobs rarely get the full rated rate because of protocol overhead, the write speed at the target and whatever else shares the pipe, so the default assumes 70%. The result is compared against the window you have, and the headroom is shown as a percentage rather than just a pass or a fail.

What the results mean

Data moved: The bytes that actually cross the link. Only the first run moves everything. After that it is the change rate, which is why a three-day seed can be followed by twenty-minute nightly runs.
Effective throughput: The rated link speed after the efficiency you set. A gigabit link that never exceeds 700 Mbps on a backup job is behaving normally, not badly.
Window used: How much of the available time the job consumes. Anything above 80% is worth acting on, because there is no slack left for the night something goes wrong.

Common problems and fixes

The estimate says the job fits, but it overran last night: Check the file count rather than the size. Per-file overhead dominates on datasets made of many small files, and no size-based estimate captures it. Compare the throughput your backup software reported during the run against the figure here; if the real rate was far lower, lower the efficiency setting to match and re-run the calculation.
The window is fixed and the job will not fit: In rough order of cost: move to synthetic full backups so a full copy is assembled at the target rather than sent over the wire, turn on source-side deduplication and compression, then look at the path itself. Seeding the first copy to a local disk and shipping it is still the fastest way to move a large dataset offsite.

Frequently asked questions

What link efficiency should I use?

Around 70% for a job crossing a network, and 85% or so for a backup to a directly attached disk. If you already know the real rate from a previous run, work backwards: divide the throughput your backup software reported by the rated speed of the link and use that.

Why does the change rate matter so much?

Because the first backup is the only one that moves everything. Once a full copy exists at the target, each run only has to send the blocks that changed, so the run time drops in proportion. A 5 TB dataset with a 2% daily change rate moves 100 GB a night, not 5 TB.

Does this cover restore time?

No, and the two are not symmetrical. Restores usually read from slower storage, often over a busier link, and may need to be reassembled from a full copy plus a chain of incrementals. If the recovery time objective is what you are planning against, time an actual restore of a representative amount of data.

Put this on your own site

Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.

Embed code

<iframe src="https://runthetests.com/embed/backup-window-calculator/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Backup Window Calculator" loading="lazy"></iframe>

Preview it at https://runthetests.com/embed/backup-window-calculator/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.