TOOL
Backup window calculator
Which compression setting finishes before morning, and what it actually saves you. Built on measured per-data-type ratio and throughput, not on vendor claims.
| Setting | Compressed size | Saved | CPU time | Transfer | Wall clock |
|---|
How it works out the numbers
No model, no curve fitting. For each compression setting the calculator holds the ratio and the throughput measured separately for each of the five data types, applies them to the share of your data that is of that type, and adds up:
compressed = Σ bytes(type) / ratio(setting, type) cpu seconds = Σ bytes(type) / throughput(setting, type) / cpu_factor transfer = compressed / link_speed wall clock = max(cpu seconds, transfer)
The max() is there because borg, restic and a tar | zstd | ssh pipeline all stream: the compressor works on the next chunk while the previous one is in flight, so the slower stage sets the pace rather than the two adding up. If your tool writes a full archive to local disk and only then uploads it, add the two figures instead of taking the larger.
The underlying ratio and throughput figures come from compress-results.jsonl and are compiled into this page by render-pages.py, so the calculator cannot fall out of step with the published measurements.
What it will get wrong
- Deduplication is not modelled, and on a second backup it dominates. Borg and restic only store chunks they have not seen before, so an incremental run touches a fraction of the data. This calculator answers "how long is a full backup of this much data", which is the first run, and the restore.
- The CPU multiplier is a guess and is labelled as one. Only the 1.0x row was measured. The others are rough scalings offered so the shape of the answer is right; if you know your machine's real throughput, the honest move is to run the benchmark on it.
- Chunked compression gives lower ratios than these. The measurements compress a whole category as one stream. Real tools compress roughly a megabyte at a time, which gives the compressor a much smaller window to find redundancy in. Treat the compressed sizes here as an optimistic bound.
- Reading the source data is not counted. Millions of small files on a spinning disk can take longer to enumerate and read than to compress, and no figure here captures that.
Everything above is checkable: the measurement it draws on, and the scripts and raw output behind that.