Module backup 

Backup run registry and the on-demand run endpoint.

A backup of a given type runs at most once at a time inside the daemon, and across types the daemon runs at most one backup at a time: a batch of due backups is linearised through a single run slot, with a quiet period between consecutive runs, rather than starting together and loading the server. BackupRegistry::ensure_run is start-or-attach: it starts a run via the injected BackupRunner when the type is idle, or hands back a subscription to the in-flight run otherwise. A subscriber sees a replay of the latest status, then live status events and a periodic heartbeat, then the run’s terminal event. BackupRegistry::running lists in-flight runs for the daemon’s status.

This serialisation is a daemon concern only; a manual bestool canopy backup invocation drives the backup driver directly and is bounded just by the cross-process lock, not by this slot.

The actual backup driver lives in the bestool binary; it’s injected here as a BackupRunner so this crate carries no backup logic of its own.

Structs

BackupRegistry

Tracks in-flight backup runs and fans their status out to subscribers.

BackupTask

Exposes GET /tasks/backup/run?type=X (start-or-attach, streaming status) and GET /tasks/backup/running (in-flight runs). Holds no periodic work; the registry drives runs on demand.

RunningBackup

One in-flight backup, for the daemon’s status.

Type Aliases

BackupRunner

Runs one backup of backup_type, emitting JSON status events into the sink and resolving when the run finishes. Injected by the binary that owns the backup driver. The runner must emit a terminal done/error event before it returns, so attached clients always see an end.