MariaDB Backup Overview
Contents
About MariaDB Backup
MariaDB Backup is an open source tool provided by MariaDB for performing physical online backups of InnoDB, Aria and MyISAM tables. For InnoDB, “hot online” backups are possible. MariaDB Backup is provided as part of MariaDB Server starting with MariaDB 10.1.23 and MariaDB 10.2.7. It reached GA status starting with MariaDB 10.1.26 and MariaDB 10.2.10. The tool is available on Linux and Windows.
MariaDB Server 10.1 introduced MariaDB Compression and Data-at-Rest Encryption. For both we have seen high interest from the users of MariaDB Server. However, existing backup solutions from our ecosystem did not support full backup capability for these features.
To address our customers and community users concerns, we decided to provide a backup solution that would support full backup capability for MariaDB Server that includes encrypted and compressed data. The most obvious way to do this was to create a solution based on the well known and used backup tool Percona XtraBackup (version 2.3.8). We extended it and named our solution MariaDB Backup.
MariaDB Backup Releases
You will not find MariaDB Backup as a separate downloadable product at this time. MariaDB Backup will be provided as a separate package included in new releases of MariaDB Server 10.1 and MariaDB Server 10.2.
MariaDB Backup is tightly connected to the storage engines XtraDB/InnoDB, and maintaining MariaDB Backup as part of the Server enables us to test it against changes in the Server and storage engines.
Installing on Linux
MariaDB Backup is a separate package in our repositories. On Debian and Ubuntu it can be installed with:
sudo apt-get install mariadb-backup-10.1
On CentOS, and RHEL it can be installed with:
sudo yum install MariaDB-backup
On Fedora and SLES/OpenSUSE it can be installed by replacing yum
in the example above with dnf
and zypper
, resepectively.
Installing on Windows
To install on Windows, select Backup utilities:
Using MariaDB Backup
MariaDB Backup is based on Percona XtraBackup 2.3.8 and therefore provides similar functionality plus:
- Backup/Restore of Data-at-Rest encrypted XtraDB/InnoDB tables.
- Backup/Restore when MariaDB Compression is used for table types XtraDB/InnoDB.
- Backup/Restore of Data-at-Rest encrypted Aria tables.
- Using MariaDB Backup for a SST with Galera Cluster, when Data-at-Rest encryption is used.
- Support of Microsoft Windows.
The command to use MariaDB Backup is
mariabackup <params>
To use MariaDB Backup for Galera Cluster SST, the script wsrep_sst_mariabackup.sh is provided and the Galera configuration setting is used:
wsrep_sst_method = mariabackup
Note that if you use the mariabackup SST method, you also need to have socat installed on the server. This is needed to stream the backup from the donor to the joiner. This is a limitation inherited from the xtrabackup-v2 SST method.
Versions
MariaDB Backup/Server Version | Maturity |
---|---|
MariaDB 10.2.10+, MariaDB 10.1.26+ | Stable |
MariaDB 10.2.7+, MariaDB 10.1.25 | Beta |
MariaDB 10.1.23 | Alpha |
Internal (How things works)
Redo log files
In MariaDB 10.2, the ib_logfile0
that is created in the prepare phase has 3 roles:
- in the source server, it is the first (possibly the only) redo log file.
- in the non-prepared backup, all the log is in ib_logfile0 (formerly called xtrabackup_logfile)
- after --prepare aka --apply-log the log file used to be deleted, but with MDEV-13311 we create a dummy ‘poison’ file. This is done to protect against someone could do a simple cp -r backup/* datadir where datadir/ib_logfile* already existed. Before MDEV-13311, there would be no backup/ib_logfile*, and the above cp command would create a situation where InnoDB can try to recover from mismatching ib_logfile*. With --copy-back this problem never existed. With MDEV-13311 we create a ‘poison’ file to prevent startup before the user fixes their script.
Limitations
MariaDB until 10.2.8
Before MariaDB 10.2.9, MariaDB Backup did not support the --export
functionality. In earlier versions, you can workaround this limitation by preparing the backup as usual (without the --export
flag), then start the server and execute FLUSH TABLES FOR EXPORT.
Note that mariabackup until 10.2.8 doesn't create empty log files and relies on the --copy-back
action executed by user (which deletes old innodb log files, if any).
For situations where users don't use --copy-back
or make sure that the data directory is empty before restoring, backups created with mariabackup until 10.2.8 may well become inconsistent/corrupted (because of the presence of leftover InnoDB logs).
Limitations compared to Percona XtraBackup:
- Backup tool based encryption (gcrypt) is not supported.
- No symlink to innobackupex - use the “--innobackupex” parameter instead.
- "--compact" and "--rebuild_indexes" are not supported
- Support for --stream=tar was removed in 10.1.24
Differences compared to Percona XtraBackup
mariabackup
creates an invalid (empty) redo-log-file,ib_logfile0
as part of the prepare stage, to protect against wrong 'cp' commands. XtraBackup uses the file namextrabackup_logfile
.