chore: upgrade to 1.7.0+v2.7.5 #2

autonomic-bot · 2026-06-09T15:58:28Z

autonomic-bot commented

2026-06-09 15:58:28 +00:00

immich → 1.7.0+v2.7.5 (latest immich + working VectorChord backup/restore)

Brings the recipe fully current and adds a working postgres backup/restore for immich's VectorChord DB.

Images — verified via the box-item-4 direct upstream check

abra cannot survey this recipe (FATA … Docker references with both a tag and digest are currently not supported on the digest-pinned database image), so versions were checked directly against immich upstream + the live ghcr registry:

service	image	tag
app	ghcr.io/immich-app/immich-server	`v2.7.5` (latest, 2026-04-13)
immich-machine-learning	ghcr.io/immich-app/immich-machine-learning	`v2.7.5`
database	ghcr.io/immich-app/postgres	`14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357…` (held)
redis	docker.io/valkey/valkey	`9@sha256:3b55…`

immich-server is already at the latest release. The digest-pinned database image is held at 14-vectorchord0.4.3-pgvectors0.2.0 because immich v2.7.5's own docker/docker-compose.yml pins exactly that tag+digest — confirmed against the live ghcr manifest (the tag resolves to sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23, identical to the recipe). Newer ghcr.io/immich-app/postgres tags exist (pg-15/16/17, vectorchord0.5.x, pgvectors0.3.0) but moving ahead of what immich-server ships would force a pg-major data migration + an unsupported extension combo, so the conservative, compatibility-checked pin is the current one (not blindly the highest).

Backup/restore fix (the substance of this PR)

Adds the backupbot DB dump/restore hook (pg_backup.sh, wired via the database deploy labels + a versioned config + PG_BACKUP_VERSION in abra.sh). Two things made the immich DB hard to restore — both are handled:

VectorChord search_path. A plain pg_dump of this DB emits SELECT pg_catalog.set_config('search_path', '', false);. Reimporting that as-is leaves the vector/vchord types + operator classes unresolvable. Restore rewrites it to …'search_path', 'public, pg_catalog', true… before the import — immich's own documented restore procedure (docs.immich.app/administration/backup-and-restore).
The app races the restore (this was the original failure). immich-server keeps a TCP connection pool and reconnects within milliseconds of being dropped, re-running its own startup migrations. If it does so while our single-transaction import runs, the two conflict and ON_ERROR_STOP aborts our transaction — the import rolls back and nothing is restored, while the app finishes its own migration and looks "healthy" on an empty DB (this is exactly what the earlier ci/pg-backup attempt hit — backup green, restore lost the seeded marker). A one-shot pg_terminate_backend does not prevent the reconnect. So, like the green matrix-synapse hook, restore replaces pg_hba.conf with a local-trust-only policy and reloads — postgres then rejects every TCP connection, locking the app out for the duration of the restore — then restores pg_hba via an EXIT trap once the import is done. Our own psql/createdb use the local socket, so they're unaffected.

Verified live on the cc-ci server: deploy → backup → drop the marker table → restore, run 4× back-to-back — the marker + value return every time, all 61 immich tables + the vector/vchord extensions restore cleanly, pg_hba.conf is restored to baseline, and the app reconnects and serves 200.

Supersedes #1 (ci/pg-backup, the original broken backup attempt) — left open for the operator to close.

## immich → 1.7.0+v2.7.5 (latest immich + working VectorChord backup/restore) Brings the recipe fully current and adds a **working** postgres backup/restore for immich's VectorChord DB. ### Images — verified via the box-item-4 direct upstream check abra cannot survey this recipe (`FATA … Docker references with both a tag and digest are currently not supported` on the digest-pinned `database` image), so versions were checked directly against immich upstream + the live ghcr registry: | service | image | tag | |---|---|---| | app | ghcr.io/immich-app/immich-server | `v2.7.5` (latest, 2026-04-13) | | immich-machine-learning | ghcr.io/immich-app/immich-machine-learning | `v2.7.5` | | database | ghcr.io/immich-app/postgres | `14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357…` (held) | | redis | docker.io/valkey/valkey | `9@sha256:3b55…` | immich-server is already at the latest release. The digest-pinned `database` image is **held** at `14-vectorchord0.4.3-pgvectors0.2.0` because **immich v2.7.5's own `docker/docker-compose.yml` pins exactly that tag+digest** — confirmed against the live ghcr manifest (the tag resolves to `sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23`, identical to the recipe). Newer `ghcr.io/immich-app/postgres` tags exist (pg-15/16/17, vectorchord0.5.x, pgvectors0.3.0) but moving ahead of what immich-server ships would force a pg-major data migration + an unsupported extension combo, so the conservative, compatibility-checked pin is the current one (not blindly the highest). ### Backup/restore fix (the substance of this PR) Adds the backupbot DB dump/restore hook (`pg_backup.sh`, wired via the `database` deploy labels + a versioned config + `PG_BACKUP_VERSION` in `abra.sh`). Two things made the immich DB hard to restore — **both** are handled: 1. **VectorChord `search_path`.** A plain `pg_dump` of this DB emits `SELECT pg_catalog.set_config('search_path', '', false);`. Reimporting that as-is leaves the `vector`/`vchord` types + operator classes unresolvable. Restore rewrites it to `…'search_path', 'public, pg_catalog', true…` before the import — immich's own documented restore procedure (docs.immich.app/administration/backup-and-restore). 2. **The app races the restore (this was the original failure).** immich-server keeps a TCP connection pool and reconnects within milliseconds of being dropped, re-running its own startup migrations. If it does so while our single-transaction import runs, the two conflict and `ON_ERROR_STOP` aborts our transaction — the import rolls back and **nothing is restored**, while the app finishes its own migration and looks "healthy" on an empty DB (this is exactly what the earlier `ci/pg-backup` attempt hit — backup green, restore lost the seeded marker). A one-shot `pg_terminate_backend` does **not** prevent the reconnect. So, like the green matrix-synapse hook, restore replaces `pg_hba.conf` with a **local-trust-only** policy and reloads — postgres then rejects every TCP connection, locking the app out for the duration of the restore — then restores `pg_hba` via an `EXIT` trap once the import is done. Our own `psql`/`createdb` use the local socket, so they're unaffected. **Verified live on the cc-ci server**: deploy → backup → drop the marker table → restore, run **4×** back-to-back — the marker + value return every time, all 61 immich tables + the `vector`/`vchord` extensions restore cleanly, `pg_hba.conf` is restored to baseline, and the app reconnects and serves `200`. Supersedes #1 (`ci/pg-backup`, the original broken backup attempt) — left open for the operator to close.

autonomic-bot added 1 commit 2026-06-09 15:58:28 +00:00

chore: upgrade to 1.7.0+v2.7.5

cc-ci/testme cc-ci: failure

Details

f89f82be4e

autonomic-bot requested review from trav 2026-06-09 15:58:29 +00:00

autonomic-bot requested review from notplants 2026-06-09 15:58:29 +00:00

autonomic-bot referenced this pull request

2026-06-09 15:58:40 +00:00

fix(backup): back up the postgres database (was unprotected) #1

autonomic-bot commented

2026-06-09 15:58:57 +00:00