How backups work

Adapters, schedules, restore discipline, and retention.

Repository-validated operator guidance View source ↗

#Adapters

Storage backends are local (path-jailed, strict permissions), S3-compatible, GCS, and Azure, selected per workload (BACKUP_ADAPTER on Beacon). Server backups pack as tar.gz under backups/<server>/<timestamp>_<name>; Beacon backup jobs name zips by millisecond timestamp. Types cover server, database, volume, and app.

#Schedules and restore

Beacon schedules per-server cron backups; the admin engine runs scheduled configurations with max-backup and retention-day caps, rolling the next run forward instead of hot-looping on failure. Restore is a staged operation — create, execute, verify, rollback — with a pre-restore snapshot, and only pending or failed restores can execute or retry. A backup is only useful after a verified restore on a node that can actually host the workload.

FLOW

Backup lifecycle

01Schedule or configtrigger

02Backup runsstore

03Adapter uploadexecute

04Restore stagedcheck

05Verify

#Retention

Retention runs in three places: per-config max backups and retention days, the catalog worker pruning managed-database backups per kind, and a sweeper failing stuck pending or running rows past the prune age. Invitations and expired claims are cleaned on the same tick.

Under /api/v1

GET|POST /servers/:id/backups   POST .../restore
GET  /servers/:id/backups/download|/verify
POST /servers/:id/backups/:name/lock|/unlock|/rename
GET|POST /managed-databases/:id/backup  .../restore