How to selective zipper for backup & disaster recovery
- Step 1Stage the files to back up — Collect the source files into one folder on the recovery machine (config tree, database dumps, the log directory). The Selective Zipper reads from local disk via the File API — nothing is pulled from or pushed to a network.
- Step 2Open the tool and drop the folder — Go to /archive-tools/selective-zipper and drop the staged folder. The folder picker preserves each file's relative path, so the backup ZIP mirrors the original directory layout for a clean restore.
- Step 3Type the scope glob — Enter one positive pattern:
**/*.conf(all configs at any depth),etc/**(one tree), orlogs/**/*.log(logs only). For DR use, prefer**-anchored patterns so a deep tree is captured regardless of the folder name prefix. - Step 4Run and confirm the scope — Click Process. Read the
Matchedcount against your expectation — if it is lower than the number of configs you know exist, the prefix or extension is off. fflate builds the ZIP locally. - Step 5Encrypt if the backup must be protected at rest — This tool does not encrypt. If the restore point holds secrets, re-run the matched set through encrypted-zip-creator for WinZip-compatible AES-256, or store
filtered.zipinside your existing encrypted vault. - Step 6Make it verifiable, then archive off-site — Chain timestamp-normalizer for stable timestamps and checksum-generator for a SHA-256 manifest. Store the ZIP + manifest in your off-site location; on restore, re-hash to prove integrity.
Common DR scope patterns
Glob patterns for typical backup scopes and what each captures. Matched against each file's full relative path; ** crosses directories, * stays within one segment.
| Backup scope | globPattern | Captures |
|---|---|---|
| All configuration files | **/*.conf | Every .conf at any depth (basename + ** coverage) |
| One config tree | etc/** | Everything under etc/ |
| Database dumps | db/**/*.sql | All .sql under db/ and subfolders |
| Today's logs | logs/2026-06-13/** | One date partition's full contents |
| YAML/JSON config (no braces) | two runs: **/*.yaml, **/*.json | Brace expansion unsupported — run twice, merge |
| Everything except a folder | not supported | No excludes — curate the staged folder or use inverse workflow |
Selective Zipper vs DR feature checklist
What this tool does and does not do, with the right sibling tool when it does not. Encryption, mtime preservation, and integrity hashing are separate steps by design.
| DR requirement | In Selective Zipper? | How to satisfy it |
|---|---|---|
| Scope by pattern | Yes | One positive glob (globPattern) |
| No upload of sensitive data | Yes | fflate runs in-tab; nothing leaves the machine |
| Encryption at rest (AES-256) | No | Re-run through encrypted-zip-creator |
| Preserve original timestamps | No | Post-process with timestamp-normalizer |
| Integrity manifest | No | checksum-generator for SHA-256 |
| Split into volumes for media limits | No | archive-splitter or multi-part-archive-creator |
| Verify an existing backup | No (generative) | archive-integrity-tester |
Cookbook
Backup-scoped recipes an operator can run during routine snapshots or mid-incident, with the verification chain that turns a ZIP into an attestable restore point.
Config-only restore point
Capture only configuration files from a staged server snapshot, leaving out binaries and data. **/*.conf catches configs at every depth.
Staged folder: server-snapshot/ server-snapshot/etc/nginx/nginx.conf server-snapshot/etc/app/app.conf server-snapshot/var/lib/data.bin globPattern: **/*.conf filtered.zip: server-snapshot/etc/nginx/nginx.conf server-snapshot/etc/app/app.conf Matched=2 Total considered=3
Database dumps only
Back up just the SQL dumps under db/, skipping WAL files and temp data. The prefix db/**/*.sql keeps scope tight.
globPattern: db/**/*.sql filtered.zip: db/2026-06-13/main.sql db/2026-06-13/analytics.sql (db/wal/*.wal and db/tmp/* excluded)
Encrypted restore point
Selective Zipper has no encryption, so add it as a second step. Build the scoped ZIP, then wrap it in AES-256.
Step 1 — Selective Zipper: globPattern: **/*.conf -> filtered.zip Step 2 — encrypted-zip-creator: input: filtered.zip password: <strong passphrase> output: configs-2026-06-13.aes.zip (AES-256)
Verifiable off-site bundle
Turn the scoped ZIP into a reproducible, attestable artifact for the off-site store: fix timestamps, then emit a hash manifest.
selective-zipper (db/**/*.sql)
-> timestamp-normalizer (epoch 0 mtime)
-> checksum-generator
filtered.zip SHA-256: 9f2c...e1
Store ZIP + manifest off-site.
On restore: re-hash filtered.zip, compare to manifest.Date-windowed log capture
Bundle one day's logs for an incident timeline. A date-prefixed glob scopes to a single partition without pulling the whole log tree.
globPattern: logs/2026-06-13/** filtered.zip: logs/2026-06-13/app.log logs/2026-06-13/access.log logs/2026-06-13/error.log (logs/2026-06-12/** and earlier excluded)
Edge cases and what actually happens
Backup needs encryption
Not in this toolThe Selective Zipper writes a plain ZIP via fflate — there is no password or AES option. For an encrypted restore point, build the scoped ZIP here, then re-run it through encrypted-zip-creator (WinZip-compatible AES-256), or store it inside an existing encrypted vault.
Original file timestamps not preserved
ExpectedThis build path writes default entry timestamps, not the source mtimes — so 'last modified' metadata in the backup will not reflect the originals. If your DR policy depends on mtimes, normalise deliberately with timestamp-normalizer and record the policy.
Backup set near the tier cap
Tier capThe documented free archive cap is 50 MB / 500 entries; a full config + dump set easily exceeds that, and since the work happens in-tab via fflate, very large sets are also bounded by browser memory. Upgrade to Pro (500 MB / 50,000) or Pro-media (2 GB / 500,000), or split the scope into multiple smaller runs (configs, then dumps, then logs) and combine with archive-merger.
Glob matched fewer files than expected
Verify scopeUnder-capture in a backup is dangerous. If Matched is lower than you expect, the cause is usually a path-prefix mismatch (the staged folder's name is in the path) or a wrong extension. Use **/*.conf to ignore the prefix and confirm the count before trusting the restore point.
Need to exclude a sensitive subfolder
By designThere is no exclude glob. Either curate the staged folder before zipping (remove the subfolder you must not back up), or use the inverse: folder-to-zip then selective-extractor with a keep-pattern.
Restore set too large for the destination medium
Not in this toolThe Selective Zipper does not split output into volumes. After building filtered.zip, split it with archive-splitter or build a multi-volume set with multi-part-archive-creator.
Verifying an existing backup, not building one
Wrong toolSelective Zipper is generative — it builds new ZIPs. To test an existing backup archive for corruption, use archive-integrity-tester; to inspect contents, use archive-previewer or file-listing-generator.
Air-gapped recovery machine
SupportedOnce the page is loaded, fflate runs locally and the tool works offline — suitable for an air-gapped DR box where the staged files must never touch a network. Load the page on a connected machine, then carry the tab/offline copy across if your policy allows.
Frequently asked questions
Can the Selective Zipper encrypt my backup?
No. This tool writes a plain ZIP via fflate with no password option. For an encrypted restore point, build the scoped ZIP here and then run it through encrypted-zip-creator, which applies WinZip-compatible AES-256 entirely in the browser.
Do my files or passwords ever leave my machine?
No. Files are read with the browser File API and zipped in-tab via fflate; nothing is uploaded. There is no server round-trip, which is the point for sensitive DR data. Only an anonymous run counter (no content) is kept for dashboard stats, and you can opt out.
How do I scope a backup to just config files?
Use **/*.conf to capture every config at any depth, or etc/** for one config tree. The ** token crosses directories, so it works regardless of how deep the configs sit. Confirm the Matched count before trusting the set.
Will the backup preserve original modified times?
No — this build path writes default entry timestamps, not source mtimes. If your DR policy relies on timestamps, run the output through timestamp-normalizer to set a known, reproducible value and document it.
Can I exclude a folder from the backup?
Not directly — only one positive glob is supported. Curate the staged folder first, or use the inverse workflow: folder-to-zip then selective-extractor with a keep-pattern.
How big a backup can I build?
Free: 50 MB / 500 entries. Pro: 500 MB / 50,000 entries. Pro-media: 2 GB / 500,000 entries. Developer: 2 GB / 500,000 / unlimited batch. For larger sets, split the scope across multiple runs or upgrade tiers.
How do I make the restore point verifiable?
Chain tools: Selective Zipper → timestamp-normalizer (stable mtime) → checksum-generator (SHA-256 manifest). Store the ZIP and manifest off-site; on restore, re-hash and compare to prove integrity.
Can I run this on a locked-down recovery box?
Yes — it needs only a browser tab, no install or admin rights, and works offline once loaded. That makes it usable mid-incident on machines where you cannot add command-line tools.
Can it split a large restore set into volumes?
No. Build filtered.zip first, then split it with archive-splitter or create a multi-volume set with multi-part-archive-creator.
Can it read or verify my existing backups?
No — it is generative (it builds ZIPs). To verify an existing backup use archive-integrity-tester; to extract one use multi-format-extractor; to inspect contents use archive-previewer.
What format is the backup ZIP?
A standard ZIP named filtered.zip (DEFLATE level 6). Any restore process reads it with unzip, Windows Explorer, macOS Finder, or a ZIP library. Relative paths from the staged folder are preserved for a clean restore.
Can I automate scheduled backups with it?
GET /api/v1/tools/selective-zipper exposes the schema, but direct server execution is unavailable (apiAvailable: false); archive tools run browser-only. Automation goes through the paired @jadapps/runner, which drives the tool in a local headless browser — sensitive data still never reaches JAD servers. For unattended OS-level backups, a native scheduler may suit better.
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.