How to streaming zip builder for backup & disaster recovery
- Step 1Stage the backup set locally — Pull the files you want to snapshot onto the machine (config dir, today's logs, an export). The tool reads them via the File API — nothing transits a network during staging or packing.
- Step 2Open the builder on a Pro+ account — Go to /archive-tools/streaming-zip-builder. It's gated below Pro. Confirm the set fits your tier: 500 MB per file / 50,000 entries on Pro, 2 GB / 500,000 on Pro+Media and Developer.
- Step 3Drop the files and Generate — Use the Drop files to process zone (accepts any type, multiple files). Drag a folder in Chromium to keep its relative paths. Click Generate — fflate deflates each entry at level 6 and assembles streaming.zip.
- Step 4Hash the output for the runbook — Backups need integrity evidence. Run the downloaded ZIP through the Checksum Generator (SHA-256 default) and record the hash in your DR runbook so a future restore can prove the archive is unaltered.
- Step 5Encrypt if it's leaving the building — The ZIP is plaintext. If the backup goes off-site or to cloud storage, re-pack the same files with the Encrypted ZIP Creator for AES-256, or wrap streaming.zip in your existing encrypted backup container.
- Step 6Store and document the restore steps — Save streaming.zip (renamed meaningfully, e.g. snap-2026-06-12.zip) to your backup target. Note in the runbook that recovery is a plain unzip — no JAD tool is required to restore.
DR bundling: what the Builder covers vs what to pair
The Streaming ZIP Builder handles bundling only. Encryption and integrity hashing are separate JAD tools — combine them for a complete DR workflow.
| DR need | Handled by Streaming ZIP Builder? | Tool to use |
|---|---|---|
| Bundle many files into one archive | Yes | Streaming ZIP Builder (Generate) |
| Preserve folder tree | Yes, when relative paths present | Streaming ZIP Builder; or folder-to-zip for a guaranteed tree |
| Encrypt the backup | No | encrypted-zip-creator |
| Integrity hash / manifest | No | checksum-generator |
| Verify a restored archive isn't corrupt | No | archive-integrity-tester |
| Split for size-limited media | No | multi-part-archive-creator |
Tier sizing for backup sets
From lib/tier-limits.ts. Per-file cap and per-archive entry limit both apply — many small files can hit the entry limit before the size cap.
| Tier | Per-file cap | Entries per archive | Typical DR fit |
|---|---|---|---|
| Pro | 500 MB | 50,000 | Daily config + log snapshots |
| Pro+Media | 2 GB | 500,000 | Larger exports, image/media backups |
| Developer | 2 GB | 500,000 | Unlimited files per job for batched snapshots |
Cookbook
Realistic DR bundling recipes, with the integrity/encryption steps the Builder leaves to sibling tools.
Daily config + log snapshot
Bundle the day's app config and logs into one ZIP for the nightly archive. Text compresses well at level 6.
Drop: etc/app.conf etc/nginx/nginx.conf logs/app-2026-06-12.log logs/access-2026-06-12.log Generate -> streaming.zip Rename -> snap-2026-06-12.zip Result: Files 4, compression ~80% (text-heavy).
Add a SHA-256 to the runbook
A backup without an integrity hash can't be proven intact on restore. Pipe the ZIP through the Checksum Generator and store the hash.
snap-2026-06-12.zip -> /archive-tools/checksum-generator (SHA-256) -> 9f2a...c1 (record in DR runbook) On restore, re-hash and compare to detect tampering/bit-rot.
Encrypt before off-site copy
The Builder's ZIP is plaintext. For an off-site copy, re-pack the same files encrypted.
Same files -> /archive-tools/encrypted-zip-creator password: <12+ chars> -> AES-256 encrypted ZIP for the off-site target Do NOT rely on the Streaming ZIP Builder for confidentiality.
Split for size-capped transport
If a DR target enforces a max attachment/object size, split the archive into parts after building.
streaming.zip (480 MB)
-> /archive-tools/multi-part-archive-creator
splitSizeMb: 25 (Gmail-cap default)
-> snap.zip.001 ... snap.zip.020
Reassemble on restore per that tool's instructions.Verify a recovered archive
Before trusting a restored backup, confirm it isn't corrupt. The Builder doesn't verify; use the integrity tester.
Restored snap-2026-06-12.zip -> /archive-tools/archive-integrity-tester -> CRC check on every entry: PASS Green = the central directory and entry CRCs are intact.
Edge cases and what actually happens
Treating the output as confidential
Plaintext riskThe Streaming ZIP Builder produces an unencrypted ZIP. Anyone with the file can read its contents. For confidential backups use the Encrypted ZIP Creator or an encrypted backup container — never assume the plaintext ZIP protects anything.
No integrity manifest in the archive
Pair a checksum toolThe Builder doesn't emit a checksum or manifest. DR best practice is a recorded SHA-256 — run the result through the Checksum Generator and store the hash in your runbook so restores are verifiable.
Backup set exceeds the per-file size cap
RejectedAny single staged file over your tier cap (500 MB Pro, 2 GB Pro+Media / Developer) is rejected before packing. Split large dumps first, or run on a higher tier.
Snapshot of thousands of small files hits the entry limit
Limit exceededThe per-archive entry limit (50,000 Pro; 500,000 Pro+Media / Developer) can bite before the size cap when snapshotting a deep tree of tiny files. Bundle subtrees into fewer archives or upgrade.
Very large backup pressures browser memory
Memory-boundThe finished ZIP is assembled as a single in-memory Blob, so a near-2 GB backup needs comparable free browser memory. For the largest DR sets, a disk-streaming CLI archiver is more robust.
Folder tree flattened on restore
Browser-dependentPaths are preserved only when files carry webkitRelativePath (e.g. dragging a folder in Chromium). Selecting loose files yields flat entries, which can complicate a structured restore. For a guaranteed tree, build with folder-to-zip.
Regulated data and where the boundary sits
By designBecause nothing is uploaded, the regulated boundary doesn't move — packing happens locally, equivalent to running a CLI on the same machine. Confirm with your compliance team, and remember the output is unencrypted until you add encryption.
Expecting incremental / dedup backups
Not supportedThis is a full-bundle tool, not an incremental backup system — it always packs exactly the files you drop, with no dedup against a prior snapshot. Use it for point-in-time bundles; use dedicated backup software for incrementals.
Frequently asked questions
Is the backup ZIP encrypted?
No. The Streaming ZIP Builder writes a plaintext DEFLATE ZIP — no password, no AES. For an encrypted backup, re-pack the same files with the Encrypted ZIP Creator (AES-256) or wrap the output in your encrypted backup container.
Does it create a checksum or manifest for the backup?
No. It reports size and compression metrics in the UI but doesn't write an integrity manifest. Run the downloaded ZIP through the Checksum Generator (SHA-256 by default) and store the hash in your DR runbook.
Does any backup data get uploaded?
No. Files are read locally and packed by fflate in the browser. Nothing transits a network — verify with DevTools -> Network during a Generate run. This is the main reason DR teams reach for it over upload-based services.
Can I restore the archive without JAD tools?
Yes. The output is a standard DEFLATE ZIP — recovery is a plain unzip on any system. No JAD client is needed for restore, which is exactly what you want for DR resilience.
What's the biggest backup I can bundle?
Per tier: 500 MB per file and 50,000 entries on Pro; 2 GB per file and 500,000 entries on Pro+Media and Developer. The assembled ZIP also has to fit in browser memory, so the practical ceiling for one job is around the 2 GB cap on top tiers.
Will it preserve my directory structure for a clean restore?
When the browser supplies relative paths (dragging a folder in Chromium), yes — entry paths use webkitRelativePath. If you select loose files, entries are flat. For a guaranteed folder tree, use folder-to-zip.
How do I verify a restored backup isn't corrupt?
Run it through the Archive Integrity Tester, which checks each entry's CRC, and compare a freshly computed SHA-256 against the hash you stored at backup time. The Builder itself doesn't verify.
Can I split the backup for size-limited targets?
Not within this tool. Build the ZIP, then use the Multi-Part Archive Creator to split it into parts (default 25 MB, matching common attachment caps). Reassemble on restore.
Is it suitable for regulated (HIPAA/PCI) backups?
The local-only architecture means data doesn't leave the machine, so the regulated boundary doesn't shift. But the output is unencrypted by default — for regulated data, always add encryption and confirm the workflow with your compliance team.
Can multiple operators use it at once?
Yes — each browser tab is an independent instance with no shared state. Tier limits apply per session. Each operator needs their own Pro+ entitlement to run it.
Does it do incremental or deduplicated backups?
No. It always packs exactly the files you drop into a full bundle — there's no comparison against a previous snapshot and no dedup. Use it for point-in-time snapshots; use dedicated backup software for incremental/dedup strategies.
What compression do I get on a typical backup?
Fixed DEFLATE level 6. Text-heavy sets (configs, logs, SQL dumps) compress to roughly 15-25% of original; already-compressed media (images, video) barely shrinks. The result panel shows the actual ratio per job.
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.