Fix backup chaining, optional dump database, and restore guard #1

Merged

MHE merged 1 commit from review-repo-config-failing-actions into main

2026-11-03 11:24:45 +01:00

MHE commented

2026-11-03 11:22:04 +01:00

Owner

Summary

Tightens the backup and restore flow so archive names, incremental chaining, and restore behavior are consistent across the backup and entrypoint scripts.

Changes

Backup naming: compress_backup now takes the full archive file name, so each backup type builds its own name. Full and incremental archives keep the <type>_<id> shape.
Incremental chain: get_latest_full searches the whole /backup tree for the newest full backup, not only today's directory. An incremental uses that full backup, even when it was taken on an earlier day. The incremental counter and name derive from the full backup's id, and the counter scans the same tree.
Dump: MARIADB_DATABASE is now optional at startup and required only for dump, which fails with a clear message when it is unset. Dump file naming is computed once and reused.
Restore guard: cleanup_restore_dir uses ${RESTORE_DIR:?} so an empty variable can never expand to rm -rf /*.
Entrypoint: prepared-chain names use local declarations separated from assignment, which keeps exit codes from being masked.
Dockerfile: sets a bash shell with pipefail for RUN steps and documents the one intentional hadolint exception.
Compose / docs: /tmp is mounted as tmpfs because the scripts take their lock there and the root filesystem is read-only. The README describes the restore chain, the backup directory layout, and the dump scope.

Why

Incrementals failed or were mis-numbered when the matching full backup came from a previous day, because lookup was limited to today's directory.
The dump path was a hard startup requirement even for full and incremental runs that never use it.
The restore cleanup had an unguarded rm -rf on a variable that could be empty.
The read-only root filesystem needs a writable /tmp for the lock files.

Testing

Verify a full backup on day N and an incremental on day N+1 chain correctly.
Verify dump fails fast without MARIADB_DATABASE, and full/incremental run without it.
Verify the restore path still refuses to run when /restore holds only a dump file.
Build the image and confirm the container starts with the read-only root filesystem and the tmpfs /tmp.

## Summary Tightens the backup and restore flow so archive names, incremental chaining, and restore behavior are consistent across the backup and entrypoint scripts. ## Changes - **Backup naming:** `compress_backup` now takes the full archive file name, so each backup type builds its own name. Full and incremental archives keep the `<type>_<id>` shape. - **Incremental chain:** `get_latest_full` searches the whole `/backup` tree for the newest full backup, not only today's directory. An incremental uses that full backup, even when it was taken on an earlier day. The incremental counter and name derive from the full backup's id, and the counter scans the same tree. - **Dump:** `MARIADB_DATABASE` is now optional at startup and required only for `dump`, which fails with a clear message when it is unset. Dump file naming is computed once and reused. - **Restore guard:** `cleanup_restore_dir` uses `${RESTORE_DIR:?}` so an empty variable can never expand to `rm -rf /*`. - **Entrypoint:** prepared-chain names use `local` declarations separated from assignment, which keeps exit codes from being masked. - **Dockerfile:** sets a bash shell with `pipefail` for `RUN` steps and documents the one intentional hadolint exception. - **Compose / docs:** `/tmp` is mounted as tmpfs because the scripts take their lock there and the root filesystem is read-only. The README describes the restore chain, the backup directory layout, and the dump scope. ## Why - Incrementals failed or were mis-numbered when the matching full backup came from a previous day, because lookup was limited to today's directory. - The dump path was a hard startup requirement even for full and incremental runs that never use it. - The restore cleanup had an unguarded `rm -rf` on a variable that could be empty. - The read-only root filesystem needs a writable `/tmp` for the lock files. ## Testing - Verify a full backup on day N and an incremental on day N+1 chain correctly. - Verify `dump` fails fast without `MARIADB_DATABASE`, and full/incremental run without it. - Verify the restore path still refuses to run when `/restore` holds only a dump file. - Build the image and confirm the container starts with the read-only root filesystem and the tmpfs `/tmp`.

MHE added 1 commit

2026-11-03 11:22:04 +01:00

Limit backup chains to full/incremental and harden tmp and restore paths

ci / compose (pull_request) Successful in 21s

Details

ci / shellcheck (pull_request) Successful in 3s

Details

ci / conventions (pull_request) Successful in 2s

Details

ci / image (pull_request) Successful in 1m8s

Details

926dca6b42