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

New issue

Open

opened 2026-07-28 06:06:07 +00:00 by claude-bot · 0 comments

claude-bot commented

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

Severity: HIGH - #26 currently backs up the wrong things

The problem

#26 backs up the database and explicitly declares photo files "replaceable by rescanning."
The user has confirmed this assumption is wrong: the physical originals are being kept, but
they are inconvenient to access and continuing to degrade.

So rescanning is not a recovery plan. It is weeks of work at best, and produces worse scans than
the ones being replaced, because the originals have aged in the meantime.

Separately, #26 and #38 only document restore. docs/circa-spec.md §6.3 and the API spec
§13.3-13.4 require in-app restore, scheduled restore verification, and displayed verification
freshness.

Scope

First-class backup of the storage tree, not just the database. Incremental, since the tree is
large and content-addressed keys make change detection cheap.
Verify backed-up files by hash after transfer.
Restore execution in the application, not only a documented procedure.
Scheduled restore verification — restore into a scratch location and confirm integrity, on a
schedule, because an unverified backup is a guess.
Surface verification freshness in the admin UI, so a stale or failing verification is visible.

Done when

Photo files are backed up, incrementally, with hash verification
Restore can be executed from the application
Restore verification runs on a schedule and its result is displayed
A real restore has been performed into a scratch environment at least once

References

docs/circa-spec.md §6.2, §6.3
docs/circa-api-spec.md §13.3-13.4

Amends: #26 (database-only scope), #38 (restore guidance only).

## Severity: HIGH - #26 currently backs up the wrong things ## The problem #26 backs up the database and explicitly declares photo files "replaceable by rescanning." **The user has confirmed this assumption is wrong**: the physical originals are being kept, but they are inconvenient to access and continuing to degrade. So rescanning is not a recovery plan. It is weeks of work at best, and produces *worse* scans than the ones being replaced, because the originals have aged in the meantime. Separately, #26 and #38 only *document* restore. `docs/circa-spec.md` §6.3 and the API spec §13.3-13.4 require in-app restore, **scheduled restore verification**, and displayed verification freshness. ## Scope - First-class backup of the storage tree, not just the database. Incremental, since the tree is large and content-addressed keys make change detection cheap. - Verify backed-up files by hash after transfer. - Restore execution in the application, not only a documented procedure. - Scheduled restore *verification* — restore into a scratch location and confirm integrity, on a schedule, because an unverified backup is a guess. - Surface verification freshness in the admin UI, so a stale or failing verification is visible. ## Done when - [ ] Photo files are backed up, incrementally, with hash verification - [ ] Restore can be executed from the application - [ ] Restore verification runs on a schedule and its result is displayed - [ ] A real restore has been performed into a scratch environment at least once ## References - `docs/circa-spec.md` §6.2, §6.3 - `docs/circa-api-spec.md` §13.3-13.4 Amends: #26 (database-only scope), #38 (restore guidance only).

claude-bot added this to the v0.4.0 milestone

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

claude-bot added the

infra

backend

labels

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

claude-bot referenced this issue

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

Implement scheduled database backup with configurable destinations #26

claude-bot referenced this issue

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