How to encrypted zip for backup & disaster recovery
- Step 1Stage the backup set locally — Pull the files to be backed up onto the recovery host (DB dump, config tree, secrets export). They are read with the File API in the tab — nothing transits a network at this stage.
- Step 2Open the tool on a Pro tier — Go to /archive-tools/encrypted-zip-creator. Sign in on Pro, Pro+Media, or Developer — this is
minTier: pro. For DR sets choose Pro+Media or Developer to encrypt up to 2 GB per file. - Step 3Drop the backup files — Drag the whole set into 'Drop files to process'. It is multi-file and accepts any type; relative paths are preserved, so a directory tree rebuilds intact on restore.
- Step 4Use a vaulted passphrase — Enter the backup passphrase (12+ characters; the 8-char floor is the hard minimum). For DR, generate it in your team's password manager / secrets vault so the restore operator can retrieve it — there is no recovery if it is lost.
- Step 5Generate and record a checksum — Click Generate, download
encrypted.zip, then run it through checksum-generator. Store the SHA-256 in your backup catalogue next to the file's location and the vault entry for its passphrase. - Step 6Ship and verify off-site — Upload the encrypted ZIP to off-site/cloud storage. After transfer, re-hash the stored copy (or use the provider's checksum) and compare to your recorded SHA-256 to confirm an intact, encrypted backup.
DR packaging checklist
Each step mapped to the tool capability that backs it. Grounded in createEncryptedZip and the archive tier limits.
| DR requirement | How this tool meets it | Pair with |
|---|---|---|
| Encrypt before transit | AES-256 (AE-2) applied in-browser; 0 bytes uploaded | — |
| Strong, non-downgradeable cipher | encryptionStrength: 3 hardcoded — no ZipCrypto, no AES-128 | — |
| Restore verification | Output is a standard ZIP with a stable byte stream to hash | checksum-generator |
| Confirm a backup is actually encrypted | Detect encryption flags on any ZIP without the password | encrypted-archive-detector |
| Test the passphrase opens the set | Verify AES entries decrypt before relying on the backup | archive-password-tester |
| Split a large set across media | Slice a built archive into fixed-size parts | multi-part-archive-creator |
Tier ceilings for backup sets
From lib/tier-limits.ts (archive family). fileBytes is per file, entryLimit is per archive. This is a Pro-tier tool, so the free row is informational only.
| Tier | Max per file | Entries per archive | Files per job | Fit for |
|---|---|---|---|---|
| Free | 50 MB | 500 | 1 | N/A — blocked (minTier pro) |
| Pro | 500 MB | 50,000 | 20 | Per-app config + small DB dumps |
| Pro+Media | 2 GB | 500,000 | 100 | Larger dataset or media bundles |
| Developer | 2 GB | 500,000 | Unlimited | Many systems per recovery batch |
Cookbook
Realistic DR packaging runs. Treat passphrases as vault-managed; never hardcode them in scripts or tickets.
Nightly config + DB dump bundle
A per-system backup: app config tree plus a logical DB dump, encrypted into one off-site bundle with structure preserved.
Stage on host: app/config/*.yml app/secrets/.env db/nightly-2026-06-13.sql (310 MB) Drop all → password from vault → Generate (Pro) Metrics: Files: 14 Encryption: AES-256 Saved: 58% Download: encrypted.zip (paths preserved: app/..., db/...) Then: checksum-generator → SHA-256 recorded in catalogue.
Verify after off-site transfer
Closing the loop: re-hash the copy that landed off-site and compare to the recorded digest before declaring the backup good.
Recorded at creation: encrypted.zip SHA-256 = 9f2a...c41b After upload to S3 / off-site disk: re-download → checksum-generator → 9f2a...c41b Match ✓ → backup intact & encrypted Mismatch ✗ → re-transfer; storage corruption suspected.
Restore-drill: confirm the passphrase still opens it
DR drills must prove the passphrase in the vault actually decrypts the archive — not just that the file exists.
Quarterly drill: fetch encrypted.zip from off-site /archive-tools/archive-password-tester paste vault passphrase → result: PASS (AES entries decrypt) If FAIL: the vault entry is stale or the file was re-created under a different passphrase — fix before you need it for real.
Confirm an inherited backup is encrypted
When you take over a backup set you didn't create, verify it is actually encrypted before trusting the off-site policy.
/archive-tools/encrypted-archive-detector drop legacy-backup.zip → Encrypted: yes Method: AES-256 (AE-2) If 'ZipCrypto' or 'none': re-package through the Encrypted ZIP Creator to bring it up to AES-256 before the next cycle.
Split a 2 GB encrypted set across media
When a bundle is too large for one transfer medium, build it then split — the split happens after encryption, so parts stay encrypted.
encrypted.zip (1.8 GB, Pro+Media) → /archive-tools/multi-part-archive-creator → part size 500 MB → encrypted.zip.001 ... .004 Recombine off-site, then extract with the passphrase.
Edge cases and what actually happens
Lost passphrase = lost backup
UnrecoverableAES-256 with a strong passphrase cannot be brute-forced and JAD stores nothing. A backup whose passphrase is lost is gone for DR purposes. Treat the passphrase as a first-class recovery asset: store it in the team vault next to the catalogue entry, and verify it in drills with archive-password-tester.
Free-tier recovery host
Blocked (upgrade)The tool is minTier: pro; a free/signed-out session gets a plan overlay, not the dropzone. Ensure the DR runbook specifies a Pro+ account (and ideally Pro+Media/Developer for 2 GB sets) so an operator isn't blocked mid-incident.
Backup set exceeds 2 GB per file
Over ceilingThe per-file tier ceiling is 2 GB (Pro+Media/Developer); a single multi-GB image won't fit and a near-ceiling job can also exhaust tab memory. Split the dataset into per-system bundles, or build then slice with multi-part-archive-creator. For full disk images, a streaming CLI backup tool is the right layer.
Filenames in the catalogue are sensitive
By designAE-2 encrypts contents, not entry names — anyone with the off-site file can list paths without the passphrase. If the directory structure itself is sensitive (e.g. customer identifiers in paths), wrap the set into one inner archive under a neutral name first, then encrypt that single file.
Already-compressed dataset shows ~0% saved
ExpectedIf the backup is already compressed (a .sql.gz, media, or a prior ZIP), the Saved metric will be near zero because AES output is incompressible and the input has no headroom. This does not indicate a problem — the encryption still applied.
Operator picks too-short passphrase under pressure
RejectedThe processor refuses anything under 8 characters with 'Choose a password of at least 8 characters (12+ recommended).' Good for safety, but it means a vault-generated 16+ char passphrase should be the standard so generation never blocks a recovery.
Output always named encrypted.zip
Rename on saveEvery run downloads as encrypted.zip. For a catalogue with one entry per system/date, rename to your convention (e.g. app01-2026-06-13.zip) immediately after download so off-site listings stay meaningful.
Restore on a host without 7-Zip/WinZip
Use a modern unzipperAE-2 needs an AES-aware reader. A bare/old unzip may report 'unsupported method' even with the right passphrase. Keep a recovery toolkit (current 7-Zip, Keka, or recent unzip) on the restore host; the archive itself is standard and not JAD-specific.
Frequently asked questions
Is my backup uploaded to JAD?
No. The archive is built in your browser by @zip.js/zip.js; the result panel shows 0 bytes uploaded and DevTools → Network confirms no outbound request for your data. The regulated boundary stays where it is — this is equivalent to running a local encryption tool.
Does this give me real encryption at rest for off-site copies?
Yes — the bundle is AES-256 (WinZip AE-2) encrypted before it leaves the machine, so whatever destination you upload to holds an encrypted file. Combine it with destination-side controls for defence in depth.
What happens if I lose the passphrase?
The backup is unrecoverable. AES-256 with a strong passphrase can't be brute-forced and JAD stores nothing. Manage the passphrase as a recovery asset in your vault, and verify it in DR drills with the Archive Password Tester.
How large a backup set can I encrypt?
Per file: Pro 500 MB, Pro+Media 2 GB, Developer 2 GB. Entries per archive go up to 500,000 on the higher tiers. For datasets above 2 GB, split into per-system bundles or build-then-split with the Multi-Part Archive Creator.
Can I verify a restore later?
Yes. Run the encrypted ZIP through checksum-generator at creation, record the SHA-256, and re-check it after transfer and before any restore. Use archive-password-tester to confirm the passphrase still decrypts the set.
Is this Pro-only?
Yes — minTier: pro. Free or signed-out sessions get a plan overlay. Specify a Pro+ account in your DR runbook (Pro+Media or Developer for 2 GB sets) so an operator is never blocked during an incident.
Can I confirm an old backup is actually encrypted?
Use encrypted-archive-detector — it reports whether a ZIP's entries are encrypted and by what method, without needing the password. If it shows ZipCrypto or none, re-package through this tool to bring it to AES-256.
Does the encryption hide which files are in the backup?
No — AE-2 encrypts file contents, not entry names. The path list is readable from the off-site file without the passphrase. If paths are sensitive, wrap the set into one inner archive under a generic name and encrypt that single file.
Will the encrypted backup be smaller?
Only if the input was compressible. Already-compressed dumps or media show ~0% Saved because AES output can't be compressed further. The metric reflects deflate before encryption; a low number is normal for backup data.
Can multiple operators use it during an incident?
Yes — each browser tab is an independent instance with no shared state. Tier limits apply per session; on paid plans there is no contention between operators working in parallel.
Does it fit HIPAA / PCI / FedRAMP boundaries?
Because nothing transits a network, using the tool doesn't move your data boundary — it's equivalent to a local encryption step. Confirm with your compliance team that browser-side processing satisfies your data-handling policy; most do for client-side encryption of data you already hold.
Can I split the encrypted backup across drives?
Yes — build the encrypted.zip here, then run it through multi-part-archive-creator to slice it into fixed-size parts. The split happens after encryption, so each part is encrypted; recombine off-site before extracting.
What if the restore host has no modern unzipper?
AE-2 needs an AES-aware reader (current 7-Zip, Keka, or recent unzip). Keep one in your recovery toolkit. The archive is a standard ZIP, so any compliant reader works — JAD does not need to be reachable to restore.
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.