deploy: postgres op een bind-mount i.p.v. een named volume #60

Merged

janpeter merged 1 commit from claude/postgres-bind-mount into main

2026-07-10 13:33:45 +02:00

janpeter commented

2026-07-10 13:33:25 +02:00

Owner

Volgt op het incident van 2026-07-09 op scrum4me-srv, waar een docker compose down -v vanuit een gekopieerde compose-file de live scrum4me-postgres vernietigde. media-organizer-postgres hing aan hetzelfde soort named volume.

Een bind-mount overleeft down -v. Dat is preventie in plaats van detectie: de compose-collision-check die we sinds het incident draaien, meldt pas achteraf en maar eens per dag.

Wat er al gebeurd is

De datadir is op 2026-07-10 (01:12 CEST) verbatim gekopieerd (cp -a via een wegwerp-container, na een clean docker stop) naar /srv/apps/media-organizer/postgres. De live container draait daar sindsdien op. Deze PR legt alleen vast wat live al waar is, zodat een git reset --hard origin/main in de deploy-flow hem niet wegvaagt.

Verificatie

Het oude volume is als losse, netwerkloze Postgres-instantie gestart (op een kopie) en exact vergeleken met de live database:


Tabellen vergeleken	54 (24 in `media_organizer`, 30 in `scrapeme`)
Methode	exacte `count(*)`, niet `n_live_tup`
Verschillen	0
Clean shutdown-checkpoint	`2026-07-09 23:11:41 UTC`, geen `postmaster.pid`

Verder: docker inspect toont type=bind, docker compose config levert dezelfde projectnaam (media-organizer), en de collisie-check geeft een ongewijzigde uitkomst.

Rollback

Het oude volume media-organizer_media-organizer-postgres (4.4G) is niet verwijderd. Terugdraaien = deze commit reverten en de container recreaten. Daarom blijft ook de volumes:-declaratie onderaan staan, voorlopig ongebruikt.

Pre-migratiedumps staan op de NAS in /mnt/nas/ssd/backups/max2-premigration-20260710/ (pg_dumpall + per-DB pg_dump -Fc), aan de ontvangende kant geverifieerd met sha256sum -c, gunzip -t en pg_restore --list.

Opruimvoorwaarden voor het oude volume: /srv/_attic/2026-07-10/VOLUMES.md — niet vóór 2026-08-10 en alleen na expliciete go.

Volgt op het incident van 2026-07-09 op `scrum4me-srv`, waar een `docker compose down -v` vanuit een gekopieerde compose-file de live `scrum4me-postgres` vernietigde. `media-organizer-postgres` hing aan hetzelfde soort named volume. Een bind-mount overleeft `down -v`. Dat is **preventie** in plaats van detectie: de `compose-collision-check` die we sinds het incident draaien, meldt pas achteraf en maar eens per dag. ## Wat er al gebeurd is De datadir is op 2026-07-10 (01:12 CEST) verbatim gekopieerd (`cp -a` via een wegwerp-container, na een clean `docker stop`) naar `/srv/apps/media-organizer/postgres`. De live container draait daar sindsdien op. Deze PR legt alleen vast wat live al waar is, zodat een `git reset --hard origin/main` in de deploy-flow hem niet wegvaagt. ## Verificatie Het oude volume is als losse, netwerkloze Postgres-instantie gestart (op een kopie) en exact vergeleken met de live database: | | | |---|---| | Tabellen vergeleken | 54 (24 in `media_organizer`, 30 in `scrapeme`) | | Methode | exacte `count(*)`, niet `n_live_tup` | | Verschillen | **0** | | Clean shutdown-checkpoint | `2026-07-09 23:11:41 UTC`, geen `postmaster.pid` | Verder: `docker inspect` toont `type=bind`, `docker compose config` levert dezelfde projectnaam (`media-organizer`), en de collisie-check geeft een ongewijzigde uitkomst. ## Rollback Het oude volume `media-organizer_media-organizer-postgres` (4.4G) is **niet** verwijderd. Terugdraaien = deze commit reverten en de container recreaten. Daarom blijft ook de `volumes:`-declaratie onderaan staan, voorlopig ongebruikt. Pre-migratiedumps staan op de NAS in `/mnt/nas/ssd/backups/max2-premigration-20260710/` (`pg_dumpall` + per-DB `pg_dump -Fc`), aan de ontvangende kant geverifieerd met `sha256sum -c`, `gunzip -t` en `pg_restore --list`. Opruimvoorwaarden voor het oude volume: `/srv/_attic/2026-07-10/VOLUMES.md` — niet vóór 2026-08-10 en alleen na expliciete go.

janpeter added 1 commit

2026-07-10 13:33:25 +02:00

deploy: postgres op een bind-mount i.p.v. een named volume

CI / docker-build (pull_request) Failing after 2s

Details

b66e86a448

Een `docker compose down -v` — of een `up` vanuit een gekopieerde compose-file
die dezelfde projectnaam draagt — wist een named volume. Op 2026-07-09 heeft
precies dat scenario op scrum4me-srv de live `scrum4me-postgres` vernietigd.
`media-organizer-postgres` hing aan hetzelfde soort volume.

Een bind-mount overleeft `down -v`. Dat is preventie in plaats van detectie: de
collisie-check die we hebben, draait één keer per dag en meldt achteraf.

De datadir is op 2026-07-10 verbatim gekopieerd (`cp -a`, clean shutdown, geen
dump/restore) naar /srv/apps/media-organizer/postgres. Alle 54 tabellen in
media_organizer en scrapeme zijn nadien op exacte `count(*)` vergeleken met het
oude volume: nul verschil.

Het oude volume `media-organizer_media-organizer-postgres` blijft bestaan als
rollback; daarom blijft ook de `volumes:`-declaratie voorlopig staan, ongebruikt.
Zie /srv/_attic/2026-07-10/VOLUMES.md voor de opruimvoorwaarden.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

janpeter merged commit 51c53c1211 into main

2026-07-10 13:33:45 +02:00

janpeter referenced this pull request from a commit

2026-07-10 13:33:45 +02:00

Merge pull request 'deploy: postgres op een bind-mount i.p.v. een named volume' (#60) from claude/postgres-bind-mount into main

janpeter referenced this pull request from a commit

2026-07-10 17:27:09 +02:00

docs(audit): document Postgres bind-mount data location (PR #60)