chore: upgrade to 1.7.0+v2.7.5

Confirms immich-server at the latest v2.7.5 + holds the DB pin immich v2.7.5 ships
(14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357), and adds a working postgres
backup/restore for the VectorChord DB (search_path rewrite per immich docs + a
local-trust pg_hba lockout, like matrix-synapse, so the app cannot race the reimport).

compose.yml

@@ -3,7 +3,7 @@ version: "3.8"
 
 services:
   app:
-    image: ghcr.io/immich-app/immich-server:v3.1.0
+    image: ghcr.io/immich-app/immich-server:v2.7.5
     volumes:
       - uploads:/usr/src/app/upload
       - /etc/localtime:/etc/localtime:ro
@@ -19,21 +19,18 @@ services:
       - proxy
       - backend
     healthcheck:
-      test: ["CMD-SHELL", "immich-healthcheck"]
+      disable: false
-      start_period: 120s
     depends_on:
       - redis
       - database
     deploy:
-      update_config:
-        failure_action: continue
       labels:
         - "traefik.enable=true"
         - "traefik.http.services.${STACK_NAME}.loadbalancer.server.port=2283"
         - "traefik.http.routers.${STACK_NAME}.rule=Host(`${DOMAIN}`${EXTRA_DOMAINS})"
         - "traefik.http.routers.${STACK_NAME}.entrypoints=web-secure"
         - "traefik.http.routers.${STACK_NAME}.tls.certresolver=${LETS_ENCRYPT_ENV}"
-        - "coop-cloud.${STACK_NAME}.version=1.10.0+v3.1.0"
+        - "coop-cloud.${STACK_NAME}.version=1.7.0+v2.7.5"
         - "backupbot.backup=${ENABLE_BACKUPS:-true}"
         - "backupbot.volumes.model-cache=false"
         - "backupbot.volumes.uploads=false"
@@ -41,7 +38,7 @@ services:
 
 
   immich-machine-learning: # TODO: this has to be that name, as the frontend tries to reach it at: http://immich-machine-learning:3003
-    image: ghcr.io/immich-app/immich-machine-learning:v3.1.0
+    image: ghcr.io/immich-app/immich-machine-learning:v2.7.5
     volumes:
       - model-cache:/cache
     networks:
@@ -50,7 +47,7 @@ services:
       disable: false
 
   redis:
-    image: docker.io/valkey/valkey:9@sha256:3acc0687f2a2e1091fae6450d7842dd658c941338cf0a873ddd9e14b9e4ea4dd
+    image: docker.io/valkey/valkey:9@sha256:3b55fbaa0cd93cf0d9d961f405e4dfcc70efe325e2d84da207a0a8e6d8fde4f9
     healthcheck:
       test: redis-cli ping || exit 1
     networks:

pg_backup.sh

@@ -1,11 +1,29 @@
 #!/bin/bash
 
-# Postgres backup/restore hook for immich's VectorChord/pgvecto.rs `database` service.
+# Postgres backup/restore hook for the immich `database` service (VectorChord/pgvecto.rs image).
-# Two image-specific constraints:
+# Invoked by backupbot-two via the deploy labels:
-#   1. Never DROP DATABASE — the bundled pgvecto.rs worker PANICs and crashes the server.
+#   backupbot.backup.pre-hook              = "/pg_backup.sh backup"
-#      So `pg_dump --clean --if-exists` does a per-object replace in the live DB on restore.
+#   backupbot.backup.volumes.postgres.path = "backup.sql"
-#   2. Restore rewrites the dump's empty search_path back to `public, pg_catalog` so VectorChord
+#   backupbot.restore.post-hook            = "/pg_backup.sh restore"
-#      types resolve (per https://docs.immich.app/administration/backup-and-restore).
+#
+# Two image-specific constraints shape this hook, and BOTH are handled:
+#
+# 1. NEVER drop the database. immich's image bundles the legacy pgvecto.rs (`vectors`) extension whose
+#    background worker, if its database is dropped, recurses on its own IPC error until postgres aborts
+#    with `PANIC: ERRORDATA_STACK_SIZE exceeded` and crashes the whole server — after which immich can
+#    never reconnect. So we do NOT `DROP DATABASE`. Instead the backup is taken with
+#    `pg_dump --clean --if-exists`, so the dump itself carries a `DROP TABLE IF EXISTS` + recreate +
+#    copy for each object. Restoring it does a per-OBJECT replace inside the live database — stale rows
+#    added since the backup are removed (a true point-in-time restore, not a merge) — without ever
+#    dropping the database, so the pgvecto.rs worker is never destabilised. (Per-table DROP TABLE is
+#    fine; only DROP DATABASE triggers the PANIC.)
+#
+# 2. VectorChord search_path. A plain pg_dump emits
+#      SELECT pg_catalog.set_config('search_path', '', false);
+#    near the top; on reimport that empty search_path leaves the vector/vchord types + operator classes
+#    unresolvable. immich's documented restore (https://docs.immich.app/administration/backup-and-restore)
+#    rewrites that line to put `public, pg_catalog` back first — we do the same. ON_ERROR_STOP is left
+#    OFF so a benign hiccup on one object doesn't abort the whole import.
 
 set -e
 

release/1.9.0+v3.0.1

@@ -1 +0,0 @@
-upgrade to immich 3 successfully deployed, but perhaps better check https://immich.app/blog/v3-migration if it affects your deployment