backups

← All modules

3 endpoints.

GET /api/v1/backups

Overview

Settings, the last run in full, and the recent run history.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response Overview Api V1 Backups Get"
}

---

POST /api/v1/backups/run

Run Now

Run the nightly backup now and return its summary.

Synchronous on purpose: the caller asked for a backup and the useful answer is whether it worked, which is only knowable when it finishes. A run that raises (a failed dump, a failed push) is reported as a 502 carrying the reason — the same failure the scheduler would record — with the summary still written to the history by run() itself.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response Run Now Api V1 Backups Run Post"
}

---

GET /api/v1/backups/site

Instance Overview

The same nightly run, seen from ONE site — whichever site is asking.

The endpoint behind the per-site Site Backups module, which exists because the estate console moved to Hub Manager on 2026-08-24 and Hub Manager is hub-only (reconcile_hub_only_menu deletes its rows off every spoke). Fifteen sites would otherwise have had a Daily Backup switch and no page anywhere that says what it did — the same "a switch is the only visible part of the system" hole this whole module was built to close, reopened one level down.

Scoped by the REQUEST's site, never by a parameter: an operator on tc asking about vdb is not a question this page answers, and a site parameter is how it would quietly become one.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response Instance Overview Api V1 Backups Site Get"
}