diff --git a/abra.sh b/abra.sh
index 1c66304..def0c38 100644
--- a/abra.sh
+++ b/abra.sh
@@ -1 +1,2 @@
 export DB_ENTRYPOINT_VERSION=v1
+export PG_BACKUP_VERSION=v1
diff --git a/pg_backup.sh b/pg_backup.sh
new file mode 100755
index 0000000..55a8365
--- /dev/null
+++ b/pg_backup.sh
@@ -0,0 +1,34 @@
+#!/bin/bash
+
+# Postgres backup/restore hook for the discourse `db` service. Invoked by backupbot-two via:
+#   backupbot.backup.pre-hook                     = "/pg_backup.sh backup"
+#   backupbot.backup.volumes.postgresql_data.path = "backup.sql"
+#   backupbot.restore.post-hook                   = "/pg_backup.sh restore"
+# Backup dumps the DB to backup.sql (gzip) inside the postgresql_data volume; backupbot archives it.
+# Restore reimports it. Discourse (the rails app + sidekiq) 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 a pg_dump backup but NO restore hook — a file-level restore did not reload
+# into the running postgres, so a restored backup silently kept the live (un-restored) state. cc-ci
+# caught this: a seeded ci_marker row was gone after restore. Same pattern as the immich / mattermost-lts
+# / ghost recipe-PRs.
+
+set -e
+
+BACKUP_FILE='/var/lib/postgresql/data/backup.sql'
+export PGPASSWORD=$(cat "${POSTGRES_PASSWORD_FILE:-/run/secrets/db_password}")
+DB_USER="${POSTGRES_USER:-discourse}"
+DB_NAME="${POSTGRES_DB:-discourse}"
+
+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 -
+}
+
+$@