From 4cab6b5146594ebd1425aa1b0aece363d9b31833 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Tue, 9 Jun 2026 21:53:18 +0000 Subject: [PATCH] fix: backup labels to backup-bot-two v2 volume syntax (restore was a no-op) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit backup-bot-two 2.4.0 snapshots paths INSIDE named volumes (backupbot.backup.volumes..path, relative to the volume root) and IGNORES the old backupbot.backup.path label. The db pre-hook wrote /postgres.dump.gz to the container's ephemeral root fs — outside every volume — so the dump never reached the snapshot and the restore post-hook failed on a missing file (gzip: /postgres.dump.gz: No such file). - db: dump into the db-data volume (transient; hooks remove it) and snapshot only that file via backupbot.backup.volumes.db-data.path — same pattern as keycloak, which passes backup/restore on this CI. Also use $POSTGRES_DB in the restore hook: the previous $PLAUSIBLE_DB is defined nowhere and only connected via libpq's username fallback. - clickhouse: snapshot only backup/events (the clickhouse-backup output) inside the event-data volume instead of the whole volume — restoring raw data files under a running server is unsafe; the post-hook performs the logical restore. --- compose.yml | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/compose.yml b/compose.yml index 037d79e..d8cb158 100644 --- a/compose.yml +++ b/compose.yml @@ -54,11 +54,15 @@ services: deploy: labels: backupbot.backup: "true" - backupbot.backup.pre-hook: sh -c 'pg_dump -U "$$POSTGRES_USER" -Fc "$$POSTGRES_DB" | gzip > "/postgres.dump.gz"' - backupbot.backup.path: "/postgres.dump.gz" - backupbot.backup.post-hook: "rm -f /postgres.dump.gz" + # backup-bot-two v2 snapshots paths INSIDE named volumes (backupbot.backup.volumes..path, + # relative to the volume root) and ignores the old `backupbot.backup.path` label — a dump + # written to the container root fs never reaches the snapshot, so restore finds nothing. + # The dump therefore lives (transiently — the hooks remove it) at the db-data volume root. + backupbot.backup.volumes.db-data.path: "postgres.dump.gz" + backupbot.backup.pre-hook: sh -c 'pg_dump -U "$$POSTGRES_USER" -Fc "$$POSTGRES_DB" | gzip > /var/lib/postgresql/data/postgres.dump.gz' + backupbot.backup.post-hook: "rm -f /var/lib/postgresql/data/postgres.dump.gz" backupbot.restore: "true" - backupbot.restore.post-hook: sh -c 'gzip -d /postgres.dump.gz && pg_restore --clean -U "$$POSTGRES_USER" --dbname="$$PLAUSIBLE_DB" < /postgres.dump && rm -f /postgres.dump' + backupbot.restore.post-hook: sh -c 'gzip -d /var/lib/postgresql/data/postgres.dump.gz && pg_restore --clean -U "$$POSTGRES_USER" --dbname="$$POSTGRES_DB" < /var/lib/postgresql/data/postgres.dump && rm -f /var/lib/postgresql/data/postgres.dump' plausible_events_db: image: clickhouse/clickhouse-server:23.4.2.11-alpine @@ -78,8 +82,11 @@ services: deploy: labels: backupbot.backup: "true" + # v2 volumes-include syntax (see db service): snapshot only the clickhouse-backup output + # inside the event-data volume — not the live raw data files (restoring those under a + # running server is unsafe; the restore post-hook performs the logical restore instead). + backupbot.backup.volumes.event-data.path: "backup/events" backupbot.backup.pre-hook: clickhouse-backup create events - backupbot.backup.path: "/var/lib/clickhouse/backup/events" backupbot.backup.post-hook: "rm -rf /var/lib/clickhouse/backup/events" backupbot.restore: "true" backupbot.restore.post-hook: clickhouse-backup restore --rm events && rm -rf /var/lib/clickhouse/backup/events