Bareos

Last modified by Sebastian Marsching on 2022/06/21 21:11

While the information compiled on this page is intended for Bareos, some of it might also apply to Bacula.

There is a separate page with information about Bacula, and most of the information there will also apply to Bareos.

Backing up a MariaDB or MySQL database running inside a Docker container

The bpipe plugin can easily be used to backup a MariaDB (or MySQL) database running inside a Docker container.

First, ensure that pluings are enabled in the file daemon configuration /etc/bareos/bareos-fd.conf:

# ...
Client {
  # ...
  Plugin Directory = /usr/lib/bareos/plugins
  # ...
}
# ...

If the configuration file also specifies the Plugin Names option, you have to make sure that it contains the bpipe plugin. If you have not specified this option, Bareos will simply load all installed plugins, which usually is okay.

Then, add the plugin definition to the appropriate FileSet section in your director configuration:

FileSet {
  # ...
  Include {
    # ...
    Plugin = "bpipe"
             ":file=/_PLUGINS/bpipe/mariadb_my_database.sql"
             ":reader=docker exec my_docker_container mysqldump my_database"
             ":writer=docker exec -i my_docker_container mysql my_database"
  }
}

Splitting the plugin string into multiple lines enhances the readability, but requires Bareos version 20 or newer. For older versions (and probably for Bacula), merge the four strings into a single line.

Obviously, my_docker_container has to be replaced with the name of the Docker container and my_database has to be replaced with the name of the database inside the Docker container. The file path can be chosen freely, but it should not collide with the path of any file that actually exists on the system where the Bareos file daemon is running. A file with the specified name will appear in the file tree of the backup, marking this file for restore in the restore job will trigger the execution of the restore command specified through the writer plugin option.

The advantage of this approach in contrast to running mysqldump as part of a Client Run Before Job script is that there does not have to be enough free disk space to store the dump as it is directly written to the backup system.

For obvious reasons, you either want to enable compression for your FileSet, because SQL dumps can get very large but usually benefit significantly from compression.

The commands in the example above a for backing up and restoring a single database (assuming that a separate Docker container is used for each application), but they can easily be changed to include multiple databases or even all databases (including the special ones internally used by MariaDB). The Bareos documentation contains a few useful examples (though not specifically for the Docker case). This approach can easily be adapted to other database systems (e.g. PostgreSQL) as well.

Using a different command for restore

By default, Bareos uses the writer command that was specified at the time of the backup for restoring. This means that changes to the plugin configuration will affect future backups (and subsequent restores of these backups), but not restores of backups that were made before the configuration changes happened.

This can be inconvenient when you want to restore the backup into a different container or need access to the actual SQL dump file. Luckily, it is possible to override the writer command at the time of restore. When running the restore job, choose to modify the Plugin Options and specify a string with a different writer. For example:

bpipe:file=/_PLUGINS/bpipe/mariadb_my_database.sql:reader=true:writer=sh -c "gzip >/tmp/restore_my_database.sql.gz"

Please note that the directory where the restored SQL dump is written must already exist (that’s why we chose /tmp here), or you have to modify the writer command to create the directory first. Please also note that the bpipe plugin itself does not execute the command through a shell, so in order to use an output redirection like in the example, you have to run the command in a shell (with sh -c "…"). In the example, we gzip the output in order to reduce the free space required for the restore action.