Browse backup history

Use the history views to confirm scheduled backups are running, spot failures early, and answer "what backups do we have for X?".

Per datasource (dashboard)

Open the datasource in Backup → Datasources. The Backup jobs card lists jobs newest-first with a total count badge and a Refresh button:

Org-wide (CLI / API)

The dashboard views are per-datasource; for a cross-database sweep use the CLI:

# newest first, across every datasource in the org
nrc snapdb backup list

# narrow to specific datasources, follow all pages, machine-readable
nrc snapdb backup list --datasource <id> --datasource <id2>
nrc snapdb backup list --all-pages --max-items 5000 -o json

The output includes datasource, status, trigger, start time, duration, and size per job — -o json plus jq answers questions like "did anything fail last night?":

nrc snapdb backup list -o json | jq '[.[] | select(.jobStatus == "failed")]'

(API: GET /backups, cursor-paginated, with a datasource_ids filter.)

Run a backup now

1. Open the datasource's detail page → ⋯ → Run backup now.
2. The dialog notes the deal up front: the ad-hoc job "runs alongside any scheduled backups and is billed at the same rate as a scheduled run."
3. If multiple policies are attached, pick one — the highest-priority enabled attachment is preselected as "(default)".
4. Click Run backup now — "Manual backup queued. It will start within a minute. Refresh the backup list to follow progress."

Requirements: the datasource must have credentials, and at least one enabled policy attached (the dialog warns otherwise). Manual runs are allowed to overlap with scheduled runs and with each other. Each manual trigger is audited (backup_job.manual_run).

Behaviour and edge cases

• Failed jobs aren't retried automatically — the next scheduled slot fires a fresh attempt. For an immediate retry, use Run backup now.
• Job records survive policy changes. Detaching or deleting a policy keeps the history; only future runs stop.
• Job records don't survive datasource deletion. Export the history first if you need it.
• Expired rows are history, not files. The archive behind an Expired badge has been deleted by retention; the row remains so your timeline stays complete.
• Need the raw engine logs? Each failed job shows a classified error summary that explains the common causes (auth, network, disk, version). If you need the full pg_dump / mongodump output to debug a stubborn failure, contact support with the job ID and we'll pull that run's logs for you. Self-serve log download is on the roadmap.

Related

• Backup jobs — the lifecycle, downloads, deletion, and the stuck-job reaper.
• Restore checks — the Restore check column, the Verify now action, and the Restore health score.
• Audit log — every job lifecycle event (queued / started / completed / failed) also lands there.