From 4ca7f4182d837b1c73632841cf883fd9c0ba241b Mon Sep 17 00:00:00 2001
From: autonomic-bot <autonomic-bot@noreply>
Date: Sat, 30 May 2026 00:38:44 +0000
Subject: [PATCH] fix(backup): reimport the postgres dump on restore (restore
 was a no-op)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The recipe dumped the DB on backup but shipped NO backupbot.restore.post-hook, and
archived the whole live PGDATA dir — so a restore extracted files under the running
postgres without reloading them, silently keeping the un-restored (live) state. A
restored backup therefore lost all data written since the snapshot.

Switch to the coop-cloud /pg_backup.sh convention (as matrix-synapse): backup =
pg_dump|gzip -> backup.sql; restore = terminate connections, FORCE-drop, recreate,
reimport the dump deterministically. Archive just backup.sql, not the whole PGDATA dir.
---
 abra.sh      |  2 ++
 compose.yml  | 13 ++++++++++---
 pg_backup.sh | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 44 insertions(+), 3 deletions(-)
 create mode 100755 pg_backup.sh

diff --git a/abra.sh b/abra.sh
index 11a0a3e..0c68799 100644
--- a/abra.sh
+++ b/abra.sh
@@ -1,2 +1,4 @@
 export ABRA_MATTERMOST_ENTRYPOINT_VERSION=v2
 export BUSYBOX_VERSION=v1
+
+export PG_BACKUP_VERSION=v1
diff --git a/compose.yml b/compose.yml
index 83a010f..82ee635 100644
--- a/compose.yml
+++ b/compose.yml
@@ -58,9 +58,13 @@ services:
     deploy:
       labels:
         backupbot.backup: "true"
-        backupbot.backup.pre-hook: "PGPASSWORD=$$(cat $${POSTGRES_PASSWORD_FILE}) pg_dump -U $${POSTGRES_USER} $${POSTGRES_DB} > /var/lib/postgresql/data/postgres-backup.sql"
-        backupbot.backup.post-hook: "rm -rf /var/lib/postgresql/data/postgres-backup.sql"
-        backupbot.backup.path: "/var/lib/postgresql/data/"
+        backupbot.backup.pre-hook: "/pg_backup.sh backup"
+        backupbot.backup.volumes.postgres_data.path: "backup.sql"
+        backupbot.restore.post-hook: "/pg_backup.sh restore"
+    configs:
+      - source: pg_backup
+        target: /pg_backup.sh
+        mode: 0555
 
 
 secrets:
@@ -69,6 +73,9 @@ secrets:
     name: ${STACK_NAME}_postgres_password_${SECRET_POSTGRES_PASSWORD_VERSION}
 
 configs:
+  pg_backup:
+    name: ${STACK_NAME}_pg_backup_${PG_BACKUP_VERSION}
+    file: pg_backup.sh
   abra_mattermost_entrypoint:
     name: ${STACK_NAME}_entrypoint_${ABRA_MATTERMOST_ENTRYPOINT_VERSION}
     file: ./entrypoint.sh
diff --git a/pg_backup.sh b/pg_backup.sh
new file mode 100755
index 0000000..5c5dca4
--- /dev/null
+++ b/pg_backup.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+
+# Postgres backup/restore hook for the `postgres` service. Invoked by backupbot-two via:
+#   backupbot.backup.pre-hook     = "/pg_backup.sh backup"
+#   backupbot.backup.volumes.postgres_data.path = "backup.sql"
+#   backupbot.restore.post-hook   = "/pg_backup.sh restore"
+# Backup dumps the DB to backup.sql (gzip) inside the postgres volume; backupbot archives it.
+# Restore reimports it. The mattermost app keeps TCP connections open to the DB, so restore must
+# terminate them and FORCE-drop before recreating, then reimport the dump deterministically — the
+# previous recipe shipped no restore hook (file-level PGDATA restore did not reload into the running
+# postgres), so a restored backup silently kept the live (un-restored) state.
+
+set -e
+
+BACKUP_FILE='/var/lib/postgresql/data/backup.sql'
+export PGPASSWORD=$(cat "${POSTGRES_PASSWORD_FILE:-/run/secrets/postgres_password}")
+DB_USER="${POSTGRES_USER:-mattermost}"
+DB_NAME="${POSTGRES_DB:-mattermost}"
+
+function backup {
+  pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
+}
+
+function restore {
+  psql -U "$DB_USER" -d postgres -c \
+    "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='${DB_NAME}' AND pid<>pg_backend_pid();"
+  psql -U "$DB_USER" -d postgres -c "DROP DATABASE ${DB_NAME} WITH (FORCE);"
+  createdb -U "$DB_USER" "$DB_NAME"
+  gunzip -c "$BACKUP_FILE" | psql -U "$DB_USER" -d "$DB_NAME" -1 -v ON_ERROR_STOP=1 -f -
+}
+
+$@
-- 
2.49.0