ops: ship a built-in backup mechanism (split from #153) #157

New issue

Open

opened 2026-08-09 01:09:33 +00:00 by rosa · 0 comments

rosa commented

2026-08-09 01:09:33 +00:00

Owner

This was generated by AI during triage.

Split from #153. #153 corrects the documentation to a safe manual snapshot (VACUUM INTO / .backup); this issue tracks whether Vernier should ship a built-in backup mechanism so operators don't have to reach for sqlite3 by hand.

Problem

Even with corrected docs, backup remains a manual, operator-driven sqlite3 incantation against a live WAL database (see #153). For the "runs on a small box, little upkeep" goal (ARCHITECTURE.md Goal #1), a self-hoster reasonably expects backup to be a first-class, hard-to-get-wrong operation rather than tribal SQLite knowledge. Media live in the same database (ADR-0017), so this file is the entire instance — the cost of a missed or botched backup is total.

Options to weigh

Built-in snapshot command — a subcommand/endpoint that runs VACUUM INTO to a target path. In-process, no new dependency, no sidecar; still operator-triggered (they wire the cron). Cheapest fit for Goal #1.
Scheduled in-process snapshots — reuse the existing in-process job runner (apalis) to take periodic snapshots to a configured directory with retention. No external process; adds a config surface and a retention policy.
Litestream — continuous streaming replication to object storage with point-in-time recovery. Strongest durability, but a sidecar process and off-box dependency, which cuts against Goal #1.

Decision needed

This is a design judgment call (durability vs. upkeep vs. added surface), so it's for a human, not an AFK agent. Deciding the scope — do nothing beyond #153, ship a snapshot command, or adopt Litestream — is the first step; an ADR should record whichever way it lands.

Depends on: #153 (docs) landing first.

> *This was generated by AI during triage.* Split from #153. #153 corrects the *documentation* to a safe manual snapshot (`VACUUM INTO` / `.backup`); this issue tracks whether Vernier should ship a **built-in backup mechanism** so operators don't have to reach for `sqlite3` by hand. ## Problem Even with corrected docs, backup remains a manual, operator-driven `sqlite3` incantation against a live WAL database (see #153). For the "runs on a small box, little upkeep" goal (ARCHITECTURE.md Goal #1), a self-hoster reasonably expects backup to be a first-class, hard-to-get-wrong operation rather than tribal SQLite knowledge. Media live in the same database (ADR-0017), so this file is the entire instance — the cost of a missed or botched backup is total. ## Options to weigh - **Built-in snapshot command** — a subcommand/endpoint that runs `VACUUM INTO` to a target path. In-process, no new dependency, no sidecar; still operator-triggered (they wire the cron). Cheapest fit for Goal #1. - **Scheduled in-process snapshots** — reuse the existing in-process job runner (apalis) to take periodic snapshots to a configured directory with retention. No external process; adds a config surface and a retention policy. - **Litestream** — continuous streaming replication to object storage with point-in-time recovery. Strongest durability, but a sidecar process and off-box dependency, which cuts against Goal #1. ## Decision needed This is a design judgment call (durability vs. upkeep vs. added surface), so it's for a human, not an AFK agent. Deciding the scope — do nothing beyond #153, ship a snapshot command, or adopt Litestream — is the first step; an ADR should record whichever way it lands. **Depends on:** #153 (docs) landing first.

rosa added the

labels

2026-08-09 01:09:42 +00:00

rosa added this to the v0.1 milestone

2026-08-12 03:34:52 +00:00

rosa modified the milestone from v0.1 to v0.2

2026-08-12 03:42:44 +00:00