How to compression level optimizer for backup & disaster recovery
- Step 1Pick a representative sample — Grab a slice of the real payload — a day's database dump, a typical document set, a build artifact. The level decision generalises from a good sample, so you avoid compressing terabytes to choose a number.
- Step 2Confirm it fits the tier cap — Each file must be under 500 MB (Pro) or 2 GB (Pro+Media/Developer). For larger samples, benchmark a sub-slice — the ratio per level is broadly representative of similar data.
- Step 3Run the benchmark (Pro) — Open /archive-tools/compression-level-optimizer on a Pro+ account, drop the sample, and Process. The tool compresses it four times — levels 1, 3, 6, 9 — and times each.
- Step 4Read against your backup window — Use the
timeMscolumn scaled to your real payload size. If level 9 adds minutes you don't have in the window, the table shows whether level 6 gets you most of the savings for a fraction of the time. - Step 5Lock the level into the real job — Apply the chosen level in your actual tooling. To build production ZIPs in-browser at that level, use Smart Archive Compressor's 0–9 level control.
- Step 6Seal and verify — If the backup must be encrypted, wrap it with Encrypted ZIP Creator; generate a SHA-256 manifest with Checksum Generator so restores can be verified.
Reading the benchmark for a backup window
How each output field maps to a backup/DR decision. Numbers are illustrative; the field shapes are exactly what optimizeLevels emits.
| Output field | What it tells the backup planner | Action |
|---|---|---|
ratio (per level) | Off-site storage and transfer savings | Higher ratio = smaller off-site footprint |
timeMs (per level) | Compression cost toward the backup window | Keep total pass time inside the window |
bestLevel | The smallest archive among 1/3/6/9 | Use only if its time fits the window |
size at level 6 vs 9 | Diminishing-returns gap | If gap is tiny, choose 6 for speed |
originalSize | Baseline before compression | Scale timing/size to full payload |
Tier limits for DR-scale samples
From lib/tier-limits.ts (archive family). Free is excluded because the tool is Pro-tier.
| Tier | Max sample size | Entries / archive | Files per job |
|---|---|---|---|
| Pro | 500 MB | 50,000 | 20 |
| Pro+Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
Cookbook
Backup-planning scenarios. Use a representative sample, then scale the result to the full payload.
Daily database dump: choosing a level for a 2-hour window
A SQL dump compresses well, but level 9 may push the pass past the window. The table shows whether 6 captures most of the savings in far less time.
Sample: db_dump.sql, 400 MB
{
"originalSize": 419430400,
"results": [
{ "level": 1, "size": 96468992, "timeMs": 3800, "ratio": "77.0%" },
{ "level": 3, "size": 88080384, "timeMs": 6100, "ratio": "79.0%" },
{ "level": 6, "size": 79691776, "timeMs": 14200, "ratio": "81.0%" },
{ "level": 9, "size": 77594624, "timeMs": 31000, "ratio": "81.5%" }
],
"bestLevel": 9
}
Decision: level 6 -> 81% in 14s; level 9 adds 0.5% for 17s more.
If the window is tight, ship level 6.Document archive for off-site transfer
Office documents (already-zipped XML internally) compress modestly; the level barely moves size, so favour speed.
Sample: 1,200 .docx/.xlsx files, 350 MB total
{
"originalSize": 367001600,
"results": [
{ "level": 1, "size": 351272960, "timeMs": 2100, "ratio": "4.3%" },
{ "level": 3, "size": 349175808, "timeMs": 3400, "ratio": "4.9%" },
{ "level": 6, "size": 348127232, "timeMs": 6900, "ratio": "5.1%" },
{ "level": 9, "size": 347602944, "timeMs": 13800,"ratio": "5.3%" }
],
"bestLevel": 9
}
Decision: ~5% either way -> use level 1 to keep the window short.Already-compressed media backups
Photo/video DR sets are entropy-dense; all levels report ~0%. The honest move is store-level, but this tool always uses DEFLATE — note in your runbook that compression buys nothing here.
Sample: 300 MB of MP4/JPEG All levels: ~0.1% ratio, output ~= input size. Runbook note: for media DR, compression level is irrelevant. Budget for ~1:1 storage and skip the high-level pass.
Sealed, verifiable backup pipeline
Choose the level, then add encryption and a checksum manifest so restores are both confidential and verifiable.
1. Level Optimizer on sample -> pick level (e.g. 6) 2. Build real archive at that level: /archive-tools/smart-archive-compressor (level 6) 3. Encrypt: /archive-tools/encrypted-zip-creator (AES-256) 4. Manifest: /archive-tools/checksum-generator (SHA-256) 5. Sync the .zip + manifest off-site
Scaling sample timing to the full payload
Extrapolate the per-level time from a sample to estimate the full backup-window cost before committing.
Sample: 400 MB, level 6 -> 14.2 s Full payload: 8 GB (20x the sample) Estimate: ~14.2 s x 20 = ~284 s (~4.7 min) at level 6 Level 9 sample: 31 s -> ~620 s (~10.3 min) If the window is 6 min, level 6 fits; level 9 does not.
Edge cases and what actually happens
Production sample on a Free account
Upgrade requiredThe tool is Pro-tier — Free shows an upgrade overlay. Use a Pro+ login before dropping any backup sample.
Sample exceeds the per-job cap
RejectedFiles over 500 MB (Pro) or 2 GB (Pro+Media/Developer) are blocked before compression. Benchmark a smaller representative slice and extrapolate.
Expecting LZMA-class ratios for the DR plan
Not supportedDEFLATE/ZIP only. Don't write an LZMA/7z ratio into a runbook based on this tool — it measures DEFLATE. Use the 7z CLI if engine choice is on the table.
Encryption assumed
Not supported hereThis tool does not encrypt. For a sealed backup, build with Smart Archive Compressor then wrap with Encrypted ZIP Creator.
Media backup shows ~0% at every level
ExpectedJPEG/MP4 are already compressed. The result is correct: level choice doesn't matter for media DR — plan for roughly 1:1 storage.
Benchmark takes ~4x a single zip
By designFour full passes run per benchmark, so a 400 MB sample compresses four times. Plan the benchmarking session itself accordingly.
Whole-dataset benchmark attempted
By designDon't compress terabytes to choose a level — sample, decide, scale. The per-level ratio generalises across similar data.
Two levels tie on size
PreservedbestLevel keeps the first (lower) level on a tie, which for backups conveniently favours the faster pass.
Output is the ZIP, named .json
ExpectedThe download is the smallest archive's bytes saved as compression-levels.json. It opens as a normal ZIP; copy the on-screen JSON for your sizing records.
Frequently asked questions
How does this help with backup windows?
The timeMs column shows each level's compression cost; scale it to your full payload to confirm the pass fits the window. The ratio column shows the size payoff so you can balance the two.
Is my backup sample uploaded anywhere?
No. fflate runs in-tab; the sample is read with the File API and never sent to a server — appropriate when the sample is production data.
Can I benchmark a whole multi-terabyte dataset?
No — per-job caps are 500 MB (Pro) / 2 GB (Pro+Media/Developer). Benchmark a representative sample and extrapolate the ratio and timing to full scale.
Does it encrypt the backup?
No. It only benchmarks DEFLATE levels. For encryption use Encrypted ZIP Creator (AES-256) after you've chosen and applied a level.
Will it tell me 7z/LZMA savings?
No. It's DEFLATE/ZIP only. If your DR plan is considering LZMA, measure that separately with the 7z CLI — don't infer it from this tool.
Which level should backups use?
There's no universal answer — that's the point of benchmarking. For compressible data, level 6 usually captures most savings cheaply; for media, any level (or store) is equivalent.
How do I make restores verifiable?
After building the archive, run Checksum Generator for a SHA-256 manifest, store it with the backup, and verify on restore.
Is it free for backup teams?
No — it's a Pro-tier tool. Free accounts can't run it. Pro, Pro+Media and Developer plans can.
Can multiple analysts benchmark at once?
Yes — each browser tab is an independent instance with no shared state. Tier limits apply per session.
Does it work on locked-down laptops?
Yes, as long as the browser supports WebAssembly. No install or admin rights are needed, since everything runs in the page.
What if the sample is media-heavy?
Expect ~0% at all levels. Document in the runbook that compression is irrelevant for that data and budget storage at roughly 1:1.
How do I apply the chosen level to the real backup?
Use Smart Archive Compressor, which exposes an explicit 0–9 level control, to build the production archive at the level the benchmark recommended.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.