Backup and disaster-recovery tooling for a Linux server: Borg backing up /home/srv/files/content — including a MariaDB database running in Docker — with an offsite mirror on Scaleway S3 via rclone.

MariaDB is never stopped during backup: dump_db.sh takes a transactionally-consistent logical dump (mysqldump --single-transaction) while the container keeps running, and the container's raw data directory is excluded from the archive entirely (a .nobackup marker file), so only the logical dump ever gets backed up. Zero DB downtime.

Components

File	Purpose
`borg-backup.sh`	Daily backup orchestrator (run from cron): dump → archive → prune → compact → integrity check → offsite sync.
`dump_db.sh`	Per-database `mysqldump`/`mariadb-dump`, atomic staging/swap. Invoked by `borg-backup.sh`.
`restore.sh`	Recovery CLI: `full` (disaster recovery), `db <name>` (single database), `file <path>` (single file/dir), `--list-archives`. Every mode supports `--dry-run`.

Quickstart

# One-time setup, deployment, cron scheduling, day-2 ops, and step-by-step
# recovery for every scenario are all in:
less RUNBOOK.md

Day to day:

./restore.sh --list-archives          # what backups exist
./restore.sh full --dry-run           # preview a disaster recovery
./restore.sh db <name> --dry-run      # preview a single-database restore
./restore.sh file <path> --dest DIR   # pull one file out of an archive

Encryption

The Borg repo at /home/srv/files/backups/borg-2025 is unencrypted by deliberate choice on this deployment — borg-backup.sh will keep printing a warning about it on every run, which is expected. See RUNBOOK.md if you want to switch to an encrypted repo.

Requirements

borg, docker, rclone, flock, a mysql/mariadb client — see REQUIRED_CMDS in borg-backup.sh. Targets Linux; flock(1) doesn't exist on macOS, so these scripts won't run as-is on a Mac.

License

None specified — internal tooling.