10 / 13
Backups & downloads
Task state machine, the three download forms, failure semantics
Task states
| State | Meaning |
|---|---|
pending | queued |
running | executing |
succeeded | export + encryption + (if configured) remote commit all succeeded |
failed | a real failure in some stage; carries an error class and first-step remediation |
canceled | user-canceled |
interrupted | instance shutdown/crash; converges via startup resume |
succeeded does NOT mean "restore-verified". Verification has its own verifyStatus shown beside the task: pending /
running / verified / failed / unsupported / skipped (the UI label
"not verified" maps to skipped).
Error classes and first steps
Eight classes: network (reachability/timeout), auth (credentials refused),
permission (insufficient privileges), client_version (no matching pg_dump
found or clients missing), disk (local space/quota), storage_upload
(remote upload or read-back failed; the local ciphertext is retained),
verification (export integrity), unknown (fallback). Failed rows render the
class's first troubleshooting step.
Download forms
- Recovery kit (
restore-job<N>.sh): hash-gated decrypt+restore script for a succeeded backup. - Local ciphertext (
backup-job<N>.dump.age): the staged artifact, same-origin download. - Bucket object (presigned URL, 15-minute TTL): only for remote-committed backups.
Obtaining any of the three requires an authenticated session (anonymous requests get 401). The third, once obtained, is a bearer URL: anyone holding it can download straight from the object store for 15 minutes without any SupaCove session — treat it like a secret and never paste it into tickets or logs.
Concurrency
One pending/running job per database at a time; duplicate triggers answer 409 (the console says a job is already queued or running).
Last updated