Files
bookstore/deploy/backup.sh
T
twooeyandClaude Sonnet 5 3876a6ba30 Fix DB password corruption via Docker secrets file mechanism
The reported bug (a generated password containing "$BRjTx3tlmSpz" got
silently blanked, breaking the DB connection) is the same Compose
interpolation issue as the earlier bcrypt hash, but this time in fields
that are genuinely user-chosen and can't just be avoided by convention.

Switched DB_PASSWORD/DB_ROOT_PASSWORD to Docker's official `_FILE`
secrets convention (MARIADB_PASSWORD_FILE / WORDPRESS_DB_PASSWORD_FILE),
backed by Compose's native `secrets:` mechanism: deploy.sh writes the raw
value to secrets/<env>/db_password, and the container reads that file
directly — the value never passes through Compose's ${VAR} interpolation
at all. Verified end-to-end with an actual `$`-containing password,
including a full deploy → backup → restore → still-serving round trip.

Also fixed along the way (found while actually testing, not assumed):
- Makefile never exported ENVIRONMENT, so `make up` alone (bypassing
  deploy.sh) would have left the new secrets path unresolved.
- deploy.sh chmod'd the secret files 600, unreadable by the container's
  own UID (www-data) — fixed to 644, relying on the containing directory
  (700) to keep other host users out instead.
- backup.sh/restore.sh still called `mysqldump`/`mysql`, which don't
  exist in the mariadb:11 image under those names — renamed to
  mariadb-dump/mariadb. (This means neither script had actually
  succeeded before now; both are verified working end-to-end here.)

The supplier/payment API keys remain passed the old way — nothing reads
them yet (bookstore-core is still a stub), so there's no live bug to fix
there; noted in .env.example that the same _FILE pattern should be used
once that code exists.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 11:36:29 -04:00

44 lines
1.8 KiB
Bash
Executable File

#!/usr/bin/env bash
# Off-host database + uploads backup (design doc §01, launch gate: "A full
# backup has been restored successfully into staging" — see restore.sh).
set -euo pipefail
ENVIRONMENT="${1:?Usage: backup.sh <staging|production>}"
export ENVIRONMENT
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
cd "$REPO_ROOT"
ENV_FILE=".env.${ENVIRONMENT}"
# shellcheck source=lib/env.sh
source "$REPO_ROOT/deploy/lib/env.sh"
TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
BACKUP_DIR="$(env_get "$ENV_FILE" BACKUP_DIR)"
BACKUP_REMOTE="$(env_get "$ENV_FILE" BACKUP_REMOTE)"
BACKUP_RETENTION_DAYS="$(env_get "$ENV_FILE" BACKUP_RETENTION_DAYS)"
BACKUP_DIR="${BACKUP_DIR:-./backups}/${ENVIRONMENT}"
mkdir -p "$BACKUP_DIR"
COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${ENV_FILE}"
echo "==> dumping database"
$COMPOSE exec -T db sh -c "exec mariadb-dump -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\"" \
| gzip > "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz"
echo "==> archiving uploads"
$COMPOSE run --rm -T wordpress tar -czf - -C /var/www/html/wp-content uploads \
> "$BACKUP_DIR/uploads-${TIMESTAMP}.tar.gz"
if [[ -n "${BACKUP_REMOTE:-}" ]]; then
echo "==> syncing to off-host storage ($BACKUP_REMOTE)"
rclone copy "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz" "$BACKUP_REMOTE/${ENVIRONMENT}/"
rclone copy "$BACKUP_DIR/uploads-${TIMESTAMP}.tar.gz" "$BACKUP_REMOTE/${ENVIRONMENT}/"
else
echo "==> BACKUP_REMOTE not set — backup stayed local only; configure rclone before launch"
fi
echo "==> pruning local backups older than ${BACKUP_RETENTION_DAYS:-14} days"
find "$BACKUP_DIR" -type f -mtime "+${BACKUP_RETENTION_DAYS:-14}" -delete
echo "==> backup complete: $BACKUP_DIR"