docs(person): ADR-039, DB diagrams, and V76 deploy runbook note
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -518,6 +518,26 @@ docker exec -i archive-db psql -U ${POSTGRES_USER} ${POSTGRES_DB} < backup-YYYYM
|
||||
|
||||
Automated backup (nightly `pg_dump` + MinIO `mc mirror` over Tailscale to `heim-nas`) is a follow-up issue. Until that ships: **manual backups are the only recovery option.**
|
||||
|
||||
### Deploy note — V76 (persons birth/death → date + precision, #773)
|
||||
|
||||
V76 drops `persons.birth_year`/`death_year` after backfilling the new
|
||||
`birth_date`/`death_date` + precision columns — a **one-way migration** (Flyway cannot
|
||||
roll it back). Before deploying:
|
||||
|
||||
1. Take a manual `pg_dump` (see above) — there is no automated nightly backup yet, so
|
||||
confirm the dump completed before starting the deploy.
|
||||
2. No maintenance window is required: the pre-check + DDL run in one atomic Flyway
|
||||
transaction, and this single-writer archive has no concurrent importers during deploy.
|
||||
|
||||
If post-deploy data issues are found, restore **only the persons table** from the
|
||||
pre-migration dump (targeted restore, not a full-database restore):
|
||||
|
||||
```bash
|
||||
pg_restore -t persons -d ${POSTGRES_DB} backup-YYYYMMDD.dump
|
||||
```
|
||||
|
||||
(For a plain-SQL dump, extract the persons COPY block instead of replaying the full file.)
|
||||
|
||||
### Rollback
|
||||
|
||||
Each release tag corresponds to a docker image tag on the host daemon (built via DooD; no registry). Rolling back to a previous tag is one command:
|
||||
|
||||
Reference in New Issue
Block a user