Fix backup/restore #12

notplants · 2026-06-02T17:26:48Z

notplants commented

2026-06-02 17:26:48 +00:00

tested backup and reform to confirm working with the fix

notplants added 5 commits 2026-06-02 17:26:49 +00:00

fix(backup): single-file mysqldump backup + reimport-on-restore hook a1e95fcbcd

The previous recipe backed the DB up as a mysqldump --tab into /var/lib/mysql-files with NO restore
hook (and the mysql data volume itself was not backupbot-labelled), so a restored backup silently
kept the live, un-restored DB state — data loss on restore. Add mysql_backup.sh (backup: gzipped
mysqldump --databases ghost into the data volume; restore: reimport it) wired via backupbot
backup.pre-hook + restore.post-hook, mirroring the postgres recipes (mattermost-lts, immich). Bump
1.2.0 -> 1.3.0.

fix(backup): use volume-relative backup path (backupbot restores it) + drop rm post-hook 6d6227f7ba

backupbot restores backed-up files by volume; an absolute backup.path is not mapped back into the
volume on restore, so the restore.post-hook reimported a missing dump. Use
backupbot.backup.volumes.mysql.path=backup.sql.gz (mirrors the postgres recipes).

fix(healthcheck): raise app start_period 1m->15m (slow fresh-DB migration) ae43ffe340

Ghost's fresh-DB first boot runs a full schema migration (dozens of CREATE
TABLEs, each a separate MySQL round-trip; ~6-9min on a small/slow node). The
1m start_period + 10x30s retries (~6min grace) is too tight there: swarm marks
the still-migrating task unhealthy and kills it mid-migration, leaving a stale
migrations_lock row so every later task deadlocks (MigrationsAreLockedError).

start_period only widens the startup grace window: a healthy check still marks
the task healthy immediately, so fast hosts are unaffected. It cannot be exposed
as an env var (abra validates the literal compose 'duration' format BEFORE env
substitution, rejecting ${VAR} / "${VAR:-1m}" with FATA 'Does not match format
duration'), so a literal bump is the only way to widen it.

chore: upgrade to 1.3.0+6.42.0-alpine fefff0d643

refactor(backup): inline backupbot hooks, drop mysql_backup.sh 26ef5e6625

Move the mysqldump/gunzip commands directly into the
backupbot.backup.pre-hook / backupbot.restore.post-hook label values
on the db service and delete the external mysql_backup.sh + its
config mount + MYSQL_BACKUP_VERSION. Matches the inline pattern used
by akaunting / engelsystem / forgejo and removes one file from the
recipe surface area.

notplants force-pushed fix-backup from 26ef5e6625 to 11bac13e30

2026-06-02 17:33:51 +00:00

Compare

notplants commented

2026-06-02 17:38:16 +00:00

@val I am merging this in because I assume fixing backup/restore is desired and there is no official maintainer listed. but I see you were the last committer so giving a ping here too

🎉 1

notplants merged commit 3c503aa42f into main

2026-06-02 17:39:09 +00:00

notplants deleted branch fix-backup

2026-06-02 17:39:10 +00:00

notplants referenced this issue from a commit

2026-06-02 17:39:11 +00:00

Merge pull request 'Fix backup/restore' (#12) from fix-backup into main

val commented

2026-06-02 20:56:58 +00:00

@notplants cool, thanks. Wasn't aware that it was not working 😯
Thanks for taking care of it ♥

@notplants cool, thanks. Wasn't aware that it was not working 😯 Thanks for taking care of it ♥