Build the admin backup management UI #38

New issue

Open

opened 2026-07-28 04:57:33 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-28 04:57:33 +00:00

Context

v0.3.0 implements scheduled backups, but they run unattended with no visibility. A backup
system whose failures are invisible provides false confidence, which is worse than knowing
you have no backups.

Scope

Admin UI for backup configuration, history, and restore guidance.

Implementation notes

Configure schedule, destinations, and retention from the admin console.
Backup history: timestamp, destination, size, duration, and verification result.
Make failures impossible to miss. A backup that has not succeeded recently should be a
prominent warning in the admin area, not a row in a list nobody opens.
On-demand backup trigger for use before a risky operation such as a large export or migration.
Show the verification result per backup â€” the integrity check from the backup issue is
only useful if its outcome is surfaced.
Document and link the restore procedure. Restore is deliberately not a one-click UI
action; it is a destructive operation better performed deliberately with documentation
in hand.
Show total space consumed and what retention will prune next.

Done when

Schedule, destinations, and retention are configurable from the UI
Backup history shows outcomes and verification results
A stale or failing backup produces a prominent warning
On-demand backup can be triggered
The restore procedure is documented and linked

References

docs/circa-spec.md section 11

Depends on: #26 (scheduled backups).

## Context v0.3.0 implements scheduled backups, but they run unattended with no visibility. A backup system whose failures are invisible provides false confidence, which is worse than knowing you have no backups. ## Scope Admin UI for backup configuration, history, and restore guidance. ## Implementation notes - Configure schedule, destinations, and retention from the admin console. - Backup history: timestamp, destination, size, duration, and verification result. - Make failures impossible to miss. A backup that has not succeeded recently should be a prominent warning in the admin area, not a row in a list nobody opens. - On-demand backup trigger for use before a risky operation such as a large export or migration. - Show the verification result per backup â€” the integrity check from the backup issue is only useful if its outcome is surfaced. - Document and link the restore procedure. Restore is deliberately not a one-click UI action; it is a destructive operation better performed deliberately with documentation in hand. - Show total space consumed and what retention will prune next. ## Done when - [ ] Schedule, destinations, and retention are configurable from the UI - [ ] Backup history shows outcomes and verification results - [ ] A stale or failing backup produces a prominent warning - [ ] On-demand backup can be triggered - [ ] The restore procedure is documented and linked ## References - `docs/circa-spec.md` section 11 Depends on: #26 (scheduled backups).

claude-bot added this to the v0.5.0 milestone

2026-07-28 04:57:33 +00:00

claude-bot added the

infra

frontend

labels

2026-07-28 04:57:33 +00:00

claude-bot referenced this issue

2026-07-28 06:06:07 +00:00

Back up photo files, and make restore executable and verified #117

claude-bot commented

2026-07-28 06:07:53 +00:00

Author

Amended by the audit of 2026-07-28.

This issue offers "restore guidance" — documentation only. The spec requires more:
docs/circa-spec.md §6.3 and the API spec §13.3-13.4 call for in-app restore execution,
scheduled restore verification, and displayed verification freshness.

An unverified backup is a guess, and a backup system whose failures are invisible is worse than
none because it removes the motivation to have another.

Tracked in #117, which also covers backing up the photo storage tree — #26's assumption that photo
files are replaceable by rescanning is wrong (the originals are kept but degrading).

**Amended by the audit of 2026-07-28.** This issue offers "restore guidance" — documentation only. The spec requires more: `docs/circa-spec.md` §6.3 and the API spec §13.3-13.4 call for **in-app restore execution**, **scheduled restore verification**, and **displayed verification freshness**. An unverified backup is a guess, and a backup system whose failures are invisible is worse than none because it removes the motivation to have another. Tracked in #117, which also covers backing up the photo storage tree — #26's assumption that photo files are replaceable by rescanning is wrong (the originals are kept but degrading).