How to folder → zip for backup & disaster recovery
- Step 1Stage the folder to snapshot — Assemble the recovery set into one parent folder — config exports, key material (handled per policy), database dumps, runbook docs. The parent folder's name becomes the ZIP filename (
dr-snapshot-2026-06.zip), which is convenient for dated retention. - Step 2ZIP it locally — Open Folder → ZIP, click the dropzone (Pick or drop a folder to ZIP), choose the parent folder. The browser enumerates the tree and
fflate.zipSyncbuilds the archive in-page. Confirm the Files count matches your expected entry count before trusting the snapshot. - Step 3Normalise timestamps if you need reproducible bundles — For audit trails where you hash each backup, run the ZIP through timestamp-normalizer (default epoch 1980-01-01). Identical source content then yields a comparable archive hash run-to-run.
- Step 4Encrypt for at-rest / off-site storage — Folder → ZIP output is unencrypted. For off-site or cloud-bucket storage of sensitive data, re-pack the same files with encrypted-zip-creator (AES-256, password 8+ chars) instead of, or in addition to, the plain bundle. Store the password in your secrets manager, never alongside the archive.
- Step 5Split to fit transport or media limits — If the bundle must cross an email gateway, a fixed USB/optical size, or an upload cap, run multi-part-archive-creator (default 25 MB parts — Gmail's cap). Keep all parts together; a missing part fails the restore.
- Step 6Verify the restore path before you rely on it — Test-extract the bundle on a clean machine, and use archive-integrity-tester to confirm CRCs. An untested backup is not a backup — verify the tree, the entry count, and (if encrypted) that the documented password opens it.
DR requirements mapped to the right tool
Folder → ZIP handles the bundling step; the rest of a DR-grade workflow is layered with sibling tools. Each stays local in the browser.
| DR requirement | Tool | Notes |
|---|---|---|
| Bundle a recovery set into one file (no upload) | Folder → ZIP | fflate, Deflate level 6, local-only, tree + timestamps preserved |
| Encryption at rest (off-site/cloud) | encrypted-zip-creator | AES-256 via zip.js; Folder → ZIP itself is plaintext |
| Fit transport / media size limits | multi-part-archive-creator | Default 25 MB parts; keep every part for restore |
| Reproducible, hashable bundles | timestamp-normalizer | Default epoch 1980-01-01 for stable hashes |
| Verify the bundle restores cleanly | archive-integrity-tester | Checks CRCs; run on a clean machine before trusting it |
| Inspect a received backup before extracting | archive-previewer | List entries without writing anything to disk |
Tier limits vs. typical DR bundle sizes
The entry-count cap is the one DR teams forget: a config tree with thousands of small files can exceed the free 500-entry limit even at a few MB. Size these against your snapshot.
| Tier | Max bytes/job | Max entries | Fits which DR bundle |
|---|---|---|---|
| Free | 50 MB | 500 | Small config/runbook snapshots |
| Pro | 500 MB | 50,000 | App config + modest data dumps |
| Pro-media | 2 GB | 500,000 | Larger seed/cold-restore sets |
| Developer | 2 GB | 500,000 | Large sets, unlimited files per job |
Cookbook
Practical DR recipes. Each keeps every step local — the data never leaves the recovery workstation during bundling.
Dated cold-restore snapshot
Bundle a recovery set into one dated archive. The parent folder name becomes the filename, which suits retention naming.
Parent folder: dr-snapshot-2026-06/ dr-snapshot-2026-06/configs/... dr-snapshot-2026-06/runbooks/restore.md dr-snapshot-2026-06/db/dump.sql Folder → ZIP -> dr-snapshot-2026-06.zip Files: 214 Saved: 71.8% (text/SQL compresses well) Store on off-site media after the encryption step below.
Encrypted off-site copy
Folder → ZIP is plaintext, so encryption is a deliberate second step for anything leaving the building.
Plain bundle (on-site, fast restore): Folder → ZIP -> dr-snapshot-2026-06.zip Encrypted copy (off-site / cloud bucket): encrypted-zip-creator, password = <from secrets vault> -> dr-snapshot-2026-06.zip (AES-256) Password stored in vault, NOT beside the archive.
Split to fit a 25 MB transport limit
When the bundle must cross an email gateway or fixed media, split into parts.
Bundle: dr-snapshot-2026-06.zip (120 MB) multi-part-archive-creator, splitSizeMb = 25 -> .z01 ... .z05 + final Restore needs ALL parts present and contiguous. Lose one part -> the whole restore fails.
Reproducible bundle for the audit log
Normalise timestamps so the same source content hashes the same every run, which makes 'did anything change?' trivial.
Run 1 (real timestamps): hash A Run 2 (real timestamps): hash B <-- differs (mtimes) With timestamp-normalizer (epoch 1980-01-01): Run 1: hash X Run 2: hash X <-- identical if content unchanged Log hash X against the snapshot date.
Verify before you trust
Test the restore on a clean machine and confirm integrity. An unverified backup is a liability.
1. Copy dr-snapshot-2026-06.zip to a clean VM 2. archive-integrity-tester -> all CRCs OK 3. Extract -> tree matches, 214 entries present 4. (encrypted) confirm vault password opens it -> Only now mark the snapshot 'restore-verified'.
Edge cases and what actually happens
Assuming the ZIP is encrypted because it's a 'backup'
PlaintextFolder → ZIP produces an unencrypted archive. Anyone with the file can read it. For DR copies that leave controlled storage, re-pack with encrypted-zip-creator (AES-256). Treat the plain bundle as on-site/working-copy only unless your storage layer encrypts at rest.
Backing up a huge volume in one pass
Memory boundfflate.zipSync builds the whole archive in memory, so a multi-GB volume can exhaust tab memory. Folder → ZIP is for point-in-time folder snapshots and seed bundles, not streaming a 40 GB nightly backup — use a real backup agent or tar on the server for that, and reserve this for curated recovery sets.
Config tree exceeds the 500-entry free cap
Tier limitA .git/node_modules/dotfile-heavy tree can blow past 500 entries while staying tiny in bytes. Prune first (empty-folder-pruner, filename-sanitizer), select fewer files, or upgrade — Pro allows 50,000 entries.
Hidden / metadata files inflate the snapshot
By design.DS_Store, Thumbs.db, and .git internals are included by default. For a clean DR bundle, run the output through filename-sanitizer and empty-folder-pruner so the restored tree contains only intended files.
Unix permissions and symlinks not preserved
Not carriedThe browser File API can't read POSIX modes or symlinks, so a ZIP restore won't carry executable bits or links. For server DR that depends on permissions, use tar -czf on the host; reserve Folder → ZIP for data/config sets where permissions are reapplied by a restore script.
One split part is missing at restore time
Restore failsMulti-part archives are useless if any part is lost — extraction needs every contiguous part. Store and transport parts together, and verify the full set count before retiring the source. Re-split from the original bundle if a part is corrupt.
Lost or unrecorded encryption password
UnrecoverableAES-256 has no backdoor. If the password for an encrypted DR bundle is lost, the data is gone. Store the password in your secrets manager keyed to the snapshot date, separate from the archive, and test-open the bundle as part of restore verification.
Backup never test-restored
High riskThe most common DR failure isn't the tool — it's an untested backup. Always verify with archive-integrity-tester and a real extraction on a clean machine. Folder → ZIP makes faithful bundles, but only a tested restore proves recoverability.
Frequently asked questions
Is the backup encrypted by default?
No. Folder → ZIP makes a plain, unencrypted ZIP. For encryption at rest, re-pack the files with encrypted-zip-creator (AES-256 via zip.js) and store the password in a secrets manager, separate from the archive. Treat the plain bundle as on-site/working-copy unless your storage encrypts at rest.
Does anything get uploaded to a server?
No. The folder is read and zipped locally with fflate.zipSync. There's no server-side path for archive tools, so regulated data (PHI, PII, financials) is never transmitted during bundling. That's the core reason it fits DR workflows over upload-first online zippers.
Can I run this on a locked-down recovery workstation?
Yes — it's a web page, so there's no installer to whitelist and no binary to sign. As long as the workstation has a modern browser, you can bundle a recovery set without admin rights. Paid tiers can additionally route jobs to the local @jadapps/runner if you've paired one.
How big a folder can I back up?
Free caps a job at 50 MB / 500 entries; Pro at 500 MB / 50,000; Pro-media and Developer at 2 GB / 500,000. Beyond that, or for streaming nightly backups of large volumes, use a dedicated backup agent or tar — Folder → ZIP builds the archive in memory and suits curated point-in-time snapshots.
Are timestamps preserved for restore?
Yes — each file's lastModified is written into the ZIP entry, so a restore recreates the original modification dates. If you instead need reproducible, hashable bundles for audit, normalise dates with timestamp-normalizer (default epoch 1980-01-01).
How do I split a bundle to fit transport limits?
Run the ZIP through multi-part-archive-creator; the default 25 MB part size matches Gmail's attachment cap, and you can set 1–4096 MB. Crucially, a restore needs every part — keep them together and verify the full set before deleting the source.
How do I verify a backup actually restores?
Test it. Use archive-integrity-tester to confirm CRCs, then extract on a clean machine and check the tree and entry count. For encrypted bundles, confirm the documented password opens it. Only a tested restore proves recoverability.
Will Unix file permissions survive in the ZIP?
No. The browser File API doesn't expose POSIX modes or symlinks, so permission bits and links aren't stored. For server DR that depends on permissions, use tar -czf on the host. Folder → ZIP is best for data/config sets where a restore script reapplies permissions.
Can I inspect a received backup before extracting it?
Yes — use archive-previewer to list every entry without writing anything to disk, which is useful when validating an off-site copy or checking a bundle from an untrusted source before extraction.
What if the encryption password is lost?
The data is unrecoverable — AES-256 has no backdoor. Always store the password in your secrets manager, keyed to the snapshot, separate from the archive, and include 'open the encrypted bundle' in your restore-verification checklist.
Does the free tier work for DR?
For small config/runbook snapshots, yes (50 MB / 500 entries). Real DR sets with database dumps and many config files usually need Pro or higher. Watch the entry-count cap as much as the byte cap — small-file trees hit 500 entries fast.
How do I keep OS junk out of the recovery bundle?
Folder → ZIP includes .DS_Store, Thumbs.db, and .git internals by default. Clean the output with filename-sanitizer (drops OS metadata files) and empty-folder-pruner (removes empty directories) so the restored tree contains only intended files.
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.