Joakim Persson
947604b25d
Adds bin/mempalace-backup and docs/backup-and-recovery.md — the mechanism a palace actually needs, none of it site-specific. Why a palace cannot be backed up with cp: it is chroma.sqlite3 (authoritative), knowledge_graph.sqlite3 (usually WAL, so -wal/-shm make a plain copy a same-instant gamble), derived HNSW segment dirs, hallways.json, the embedder descriptor, and a HIDDEN .mempalace/origin.json. Both SQLite files are therefore copied through the online-backup API. Two bugs are documented because both produce a backup that looks fine: "$PALACE"/*/ silently skips the hidden dir, and per-directory rsync collides the identically named data_level0.bin in every HNSW segment. Treating the palace as one tree fixes both and makes a backup a faithful palace IMAGE, so restore is a copy rather than a procedure. Two modes: hot (default, zero downtime, ~4 s, index may lag but SQLite is authoritative and repair --mode from-sqlite rebuilds) and cold (--cold, ~5 s downtime, byte-consistent, restart trapped so a failed run still brings the server back). Verification runs on the COPY — quick_check plus row counts — and the backup is committed by mv only after it passes, with retention pruned only after a verified commit, so a broken new backup cannot delete the last good one. Documented because they are easy to get wrong: the sqlite3 CLI is often absent where the Python module is present; mempalace_embedder.json must be restored with the drawers or search silently degrades; a tested restore means running status AND search against the restored copy, since search is what actually exercises the index; mempalace-serve is a USER unit, so root systemctl reports "not found"; Persistent=true is what makes a missed window run after boot; and installing against the system Python couples the palace's availability to distribution upgrades, with the uv-managed-interpreter fix plus the two PATH traps that bite scripted upgrades. Also moves docs/synlig-primary-runbook.md out to a private fleet repository, leaving a stub that explains the split, since a host inventory is operator data for one deployment rather than part of a public toolkit. The path stays valid so existing links do not break. Remaining host references in the README, RFCs and ARCHITECTURE are left alone deliberately: they are load-bearing prose, contain no secrets, and are best generalised as they are next edited rather than in one churn-heavy pass.
22 lines
1.0 KiB
Markdown
22 lines
1.0 KiB
Markdown
# (moved) primary-host runbook
|
|
|
|
This file used to contain the deployment runbook for one specific primary host —
|
|
its hostname, addresses, user, service wiring and rollback steps.
|
|
|
|
**That content now lives in a private repository**, because a host inventory is
|
|
operator data for one deployment, not part of the toolkit. This repository is
|
|
public and keeps only host-agnostic *mechanism*.
|
|
|
|
What lives where:
|
|
|
|
| Content | Home |
|
|
|---|---|
|
|
| How to expose a palace over HTTP, and the Host/Origin pin | `docs/phase-1-exposure-runbook.md` (here) |
|
|
| Why a palace needs a special backup, and how to restore one | `docs/backup-and-recovery.md` (here) |
|
|
| Unit/timer/plist templates | `contrib/` (here) |
|
|
| Which machine is primary, its addresses, users, tunnels, offsite target | private fleet repository |
|
|
| Per-host feeder device names and schedules | private fleet repository |
|
|
|
|
If you are looking for the mechanism, the two runbooks above are the same
|
|
procedures with `<PRIMARY_HOST>` and `<USER>` in place of one site's specifics.
|