QuarkPan Backup Suite
Use this skill to deploy a production-safe backup workflow with these goals:
- Keep automated workspace backups on Quark Drive.
- Use the OpenList-style non-parallel whole-file upload flow for cloud writes.
- Avoid QuarkPan's fragile large-file
parallel_upload/X-Oss-Hash-Ctxpath. - Enforce account binding so uploads cannot silently go to a wrong account.
- Keep system rollback snapshots manual-only (no auto overwrite risk).
- Provide reproducible restore steps and distributable skill package.
Current upload architecture
The current production path is:
- QuarkPan remains responsible for QR login / auth status / account binding guard.
upload-quarkpan.shruns the account guard before any cloud write.- Actual cloud writes use
quark-openlist-upload.py, a standalone OpenList/Alist-compatible uploader:- no
parallel_upload: true - no synthetic
X-Oss-Hash-Ctx - uses server-returned
metadata.part_size - uses server-returned
upload_urlhost - uploads archive and
.sha256as whole files
- no
CLOUD_SPLIT_FALLBACK=0by default. Do not split backups unless the user explicitly requests a temporary emergency workaround.
Workflow
- Run preflight checks with
scripts/check_env.sh. - Configure backup policy using
references/commands.md. - Enforce account guard (
bind,check,rotate-*) before uploads. - Verify restore path with dry-run first.
- Keep Lighthouse snapshots manual-only; use weekly prompt policy.
- Package/share this skill with
package_skill.py.
Guardrails
- Do not auto-apply destructive restore.
- Do not auto-create system snapshots by cron.
- Require explicit confirmation for snapshot creation and snapshot rollback.
- Keep cloud upload failure non-fatal for local backup success.
- Do not log or publish Quark cookies, preview URLs, or auth tokens.
- Do not revive the old QuarkPan large-file multipart path as the default uploader.
References
- Command cookbook:
references/commands.md - Security and rotation policy:
references/security-policy.md - Sharing/export steps:
references/share.md
