How to smart compressor for backup & disaster recovery
- Step 1Stage the backup set locally — Pull the files to a local folder (from a snapshot mount, export, or staging area). The Smart Compressor reads from disk via the browser — nothing transits a network at any point.
- Step 2Manifest first (chain of custody) — Before compressing, run /archive-tools/checksum-generator over the set to capture SHA-256 hashes. Keeping the manifest separate lets a restore verify each file independent of the archive.
- Step 3Compress the set — Open /archive-tools/smart-archive-compressor, drop the folder, and pick a level:
0for already-compressed media (images/video backups),6for mixed sets,9for log/text-heavy data. Click Generate. - Step 4Encrypt for off-site storage — For anything leaving your perimeter, do not ship the plain ZIP. Run /archive-tools/encrypted-zip-creator to wrap the set in AES-256 with a strong password — that is the step that makes it an encrypted off-site backup.
- Step 5Normalize timestamps (optional) — If your DR policy wants reproducible, comparable archives across nights, pass the ZIP through /archive-tools/timestamp-normalizer at a fixed date so identical content yields identical bytes.
- Step 6Verify and store — Confirm the ZIP opens with /archive-tools/archive-integrity-tester, record its checksum, and move it to the vault. The integrity test catches a truncated download before it becomes a failed restore.
Smart Compressor in a DR pipeline
The compressor is one stage. Encryption, manifesting, and verification are separate, dedicated tools.
| DR need | Tool | What it does |
|---|---|---|
| Bundle a backup set | Smart Compressor | Builds one compressed.zip from the folder (DEFLATE level slider) |
| Chain-of-custody hashes | checksum-generator | SHA-256 / SHA-1 / MD5 manifest of every entry |
| Encrypt before off-site | encrypted-zip-creator | AES-256 password protection on the ZIP |
| Reproducible nightly bytes | timestamp-normalizer | Fixes every entry's date so identical content matches |
| Pre-restore integrity check | archive-integrity-tester | Confirms the ZIP opens and CRCs pass |
| Split for media constraints | archive-splitter | Cuts a big ZIP into size- or count-bounded parts |
Tier limits for backup sets
Match the tier to your nightly set size. Watch the entry-count cap on backups with many small files.
| Tier | Max bytes per job | Max entries | Typical DR fit |
|---|---|---|---|
| Free | 50 MB | 500 | Ad-hoc config/key bundles |
| Pro | 500 MB | 50,000 | Daily app-data sets |
| Pro-media | 2 GB | 500,000 | Media/image backups |
| Developer | 2 GB | 500,000 | Unattended/scripted-feel nightly sets |
Cookbook
Realistic DR bundling runs. Filenames are illustrative; the metrics format matches the compressor's result panel.
Config + key bundle on Free
A small, high-value set — app configs and cert keys — fits well within the Free cap and compresses hard because it is mostly text.
Dropped (level 9, Free): etc/app/config.yaml 18 KB etc/app/secrets.env 2 KB certs/server.crt 4 KB Metrics: Files: 3 Level: 9 Saved: 71% Original: 24 KB -> compressed.zip 7 KB Next: encrypt before off-site (keys must not ship in plaintext).
Nightly app-data set on Pro
A mixed nightly export of database dumps and assets. Level 6 balances CPU against storage for a recurring job.
Dropped (level 6, Pro): db/dump-2026-06-13.sql 210 MB assets/... 2,400 files, 80 MB Metrics: Files: 2,401 Level: 6 Saved: 64% Original: 290 MB -> compressed.zip 104 MB
Media backup — skip compression
An image/video backup is already entropy-dense. Level 0 packages it instantly; level 6 would burn CPU for ~0% gain.
Dropped (level 0, Pro-media): photos/2026/... 5,200 JPGs, 1.4 GB clips/... 18 MP4s, 380 MB Metrics: Files: 5,218 Level: 0 Saved: 0.2% Original: 1.78 GB -> compressed.zip 1.78 GB (packaged)
Full encrypted off-site chain
The accurate way to produce an 'encrypted off-site backup' — two tools, in order. The Smart Compressor never encrypts on its own.
1. checksum-generator -> manifest.txt (SHA-256 per file) 2. smart-archive-compressor (level 6) -> compressed.zip 3. encrypted-zip-creator (AES-256, strong pw) -> encrypted.zip 4. archive-integrity-tester (pw) -> PASS 5. Move encrypted.zip + manifest.txt to the vault.
Reproducible nightly archives
DR teams that compare nights want identical bytes for identical content. Normalize timestamps after compressing.
smart-archive-compressor (level 6) -> compressed.zip timestamp-normalizer (1980-01-01) -> reproducible.zip Two nights with no content change now produce the same bytes and the same checksum -> trivially diffable.
Edge cases and what actually happens
Assuming the output is encrypted
RejectedThe Smart Compressor produces an UNENCRYPTED ZIP. Shipping it off-site as-is exposes the data. Always follow with /archive-tools/encrypted-zip-creator for AES-256 before the archive leaves your perimeter.
Backup set over the tier cap
Tier limitFree stops at 50 MB, Pro at 500 MB, Pro-media and Developer at 2 GB. A nightly set above your cap is blocked — upgrade, or split the set and compress in chunks.
Thousands of tiny backup files
Tier limitThe entry-count cap (500 Free / 50,000 Pro / 500,000 higher) can trip before the byte cap on file-dense backups. Prune empties with /archive-tools/empty-folder-pruner or move to a higher tier.
Restore years later needs the format
SupportedOutput is a standard ZIP with a ZIP 2.0 central directory — no proprietary container to go obsolete. Any future unzip or archive utility restores it.
Media backup barely shrinks
ExpectedImage and video backups are already compressed; DEFLATE cannot help. Set the level to 0 so the job packages quickly instead of wasting operator time.
Need to compare two nights
PreservedWithout normalization, lastModified timestamps make identical content differ byte-for-byte. Run /archive-tools/timestamp-normalizer so unchanged nights produce identical archives and an /archive-tools/archive-diff shows only real changes.
Large job exhausts the workstation
Memory limitzipSync is in-memory; a 2 GB job needs headroom. On constrained DR boxes, build large ZIPs with /archive-tools/streaming-zip-builder to keep memory bounded.
Vault has a per-file size limit
SupportedIf the destination caps individual file size, compress then split with /archive-tools/archive-splitter by size or entry count; each part is a complete, restorable ZIP.
Compliance asks 'where did the data go?'
By designNowhere off-device during compression — the bytes never leave the browser tab, equivalent to a local CLI. Confirm with your team that local browser processing satisfies your data-handling policy; for most it does.
Corrupted source file in the set
ExpectedThe compressor packages whatever bytes it reads — it does not validate source content. Hash the set first with /archive-tools/checksum-generator so a bad source file is caught before it lands in the backup.
Frequently asked questions
Does this encrypt my backup?
No. The Smart Compressor produces an unencrypted ZIP. For an encrypted off-site backup, follow it with /archive-tools/encrypted-zip-creator (AES-256) — or build the encrypted ZIP there directly.
Is my backup data uploaded anywhere?
No. Files are read with the browser File API and compressed in-tab. Nothing transits a network during compression, which is what makes it safe for sensitive DR data.
What format will future restores need?
A standard ZIP reader — that is all. The output uses the ZIP 2.0 central directory with UTF-8 filenames, so any future unzip or archive utility restores it.
How do I keep chain of custody?
Generate a SHA-256 manifest with /archive-tools/checksum-generator before compressing, store it alongside the archive, and verify hashes on restore.
What's the size limit for a nightly set?
Free 50 MB, Pro 500 MB, Pro-media and Developer 2 GB. There is also an entry cap (500 / 50,000 / 500,000) that file-dense backups can hit first.
Can I make nightly archives reproducible?
Yes. Compress, then /archive-tools/timestamp-normalizer at a fixed date. Unchanged content then yields identical bytes night to night, which makes diffs and dedupe trivial.
What compression level should DR use?
0 for media-heavy sets (no gain available), 6 for mixed daily data, 9 for log/text-heavy exports where storage matters more than CPU.
Can I split a big backup for storage limits?
Yes — compress, then /archive-tools/archive-splitter cuts the ZIP into size- or count-bounded parts, each a complete archive.
Does it work on locked-down DR workstations?
Yes. There is no binary to install — it runs in any modern browser, which suits hardened, no-admin environments.
How do I verify a backup before storing it?
Run /archive-tools/archive-integrity-tester on the ZIP. It confirms the archive opens and the CRCs pass, catching a truncated file before it becomes a failed restore.
Can multiple operators use it at once?
Yes. Each browser tab is an independent instance with no shared state; tier limits apply per session.
Is it suitable for regulated data (HIPAA/PCI)?
Because compression happens locally with no upload, the regulated boundary does not move. Confirm with compliance that local browser processing matches your policy; for most it is equivalent to a local CLI.
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.