Backup jobs
One execution of a backup. The audit record of what ran, when, and where it landed.
A backup job is a single execution record. Backup creates one job per policy run, plus one for any manual trigger. Jobs are what you look at to audit "did a backup run yesterday?", "how big did it get?", and "can I still download last week's dump?".
What a job records
Prop
Type
Status lifecycle
queued → running → success
→ failed
→ partial (rare – some part succeeded, some didn't)
→ canceled (only if the worker was stopped mid-run)A job sits in queued while waiting for a worker. The wait is usually
sub-second; it grows under load or when many policies fire
simultaneously.
A stuck-job reaper sweeps periodically to reconcile rows whose worker disappeared (e.g., the container was killed before reporting). Reaped jobs get a terminal status and an audit-log entry explaining the reason.
How a backup is taken
Credentials decrypt
The worker decrypts your database credentials inside the container.
Dump streams
pg_dump --format=custom (Postgres) or mongodump --archive (MongoDB)
runs against the database. Stdout is piped through gzip and streamed
straight to S3 – no local disk, no temp files.
Result reported
On success, the worker reports the S3 location and final size back to the Backup control plane.
Audit row written
The job's lifecycle (queued / started / completed / failed) is recorded in the audit log.
See Encryption and security for details on credential handling and at-rest encryption.
Download a backup
Successful, non-expired backups can be downloaded:
Open Backup jobs
Open the data source in app.norcube.com → Backup.
Click Download
In Backup jobs, click the Download action on a job's row. The dashboard requests a short-lived signed URL and starts the download.
For BYO destinations, downloads use the same flow and produce a presigned URL against your bucket.
Delete a backup
Old backups age out automatically per the policy's retention rule. You can also delete a specific backup manually from the row's combined Download / Delete action.
The S3 object is removed and the job record is marked deleted with the
reason user_deleted in the audit log.
Behaviour and edge cases
- Long-running jobs hold no locks on your database beyond what
pg_dump/mongodumpitself takes – for Postgres, anACCESS SHARElock per table. Reads and writes during a backup are fine; DDL waits until the backup finishes. - Failures are sticky. A failed job stays failed – there's no automatic retry within a single scheduled tick. The next scheduled run attempts again normally.
- Canceled jobs leave no S3 object. Multipart S3 uploads are aborted by S3's own multipart timeout; no partial files are charged to your account.
- Expired backups stay in history. You see when they ran and how big they were, but the Download action is disabled and the S3 object has been deleted.
- No PITR yet. Every backup is a full logical dump. Point-in-time recovery is on the roadmap.
- Restore endpoints are not yet live. The routes exist but return
501 Not Implemented. To restore today, download the backup file and usepg_restore/mongorestoreagainst your target database.
Related
- Browse backup history – filter, paginate, manual run-now.
- Encryption and security.
- Audit log – cross-resource activity timeline.