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.
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).
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.
