brainbitsgmbh/mariadb-backup repository overview

⁠MariaDB Backup

This image allows a simple backup strategy for mysql and mariadb databases. Backups are created via mariadb-dump and gziped, and can be restored with this image by just changing a single environment variable.

⁠Backup strategy

This image follows a simple strategy for keeping or removing backuped dumps:

• It checks whether there already is a file in the output directory that was created on the current day.
  • If no, a new backup will be created and treated (and named) as a "daily" backup.
  • If yes, a new backup will be created and treated (and named) as an "hourly" backup.
• Depending on whether it created a "daily" or "hourly" backup, it might remove certain older backup files:
  • Daily: It will remove all daily backups (files starting with the name daily-*) that are older than a specified amount of days.
  • Hourly: It will remove all hourly backups (files starting with the name hourly-*) and only keeps a specified amount of files.

This strategy ensures, that there are always a certain amount of backup files available from the last couple of days, but also that there are at least a few recent backups available too, without storing too many backups.

⁠Variables

The following environment variables can be used to configure the script:

⁠Examples

Example creating and restoring a backup using docker run:

# Create a backup. It will automatically create a link called `latest` to that backup.
docker run -it --rm -e "MODE=backup" -e "DATABASE_DSN=mysql://MyDbUser:[email protected]/my-database" -v "$(pwd)/backup:/backup" brainbitsgmbh/mariadb-backup:latest

# Restore the `latest` backup.
docker run -it --rm -e "MODE=restore" -e "DATABASE_DSN=mysql://MyDbUser:[email protected]/my-database" -v "$(pwd)/backup:/backup" brainbitsgmbh/mariadb-backup:latest

⁠S3 Authentication

This script uses the aws cli to interact with S3. Please consult the official documentation⁠ on how to configure the aws cli. But some of the more common variants to authenticate are:

• If you already have an authenticated aws client on your machine and you want to run this script locally, you can just mount your configuration with -v ~/.aws:/root/.aws.
• If you run this inside a Kubernetes cluster in AWS you'll likely want to use the IAM role of the node to authenticate. In that case it should be enough to set the proper service account for the pod.
• You should also be able to pass the variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to the container to authenticate with S3.

⁠Troubleshooting

⁠The script cannot connect to my database

Make sure that you enter a valid DSN that can also be reached from withing the docker container the script is running in. If your DSN includes localhost it will likely not work, because the container cannot reach the database on your local machine via localhost. In that case you can try host.docker.internal instead, as seen in the example above.