Mariabackup Overview
Contents
About Mariabackup
Mariabackup 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. Mariabackup 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 Mariabackup.
Mariabackup Releases
The mariabackup executable is included in tar.gz and zip packages. DEB or RPM packages include it as a separate RPM/DEB. Mariabackup is available starting with MariaDB 10.1.23.
Installing on Linux
Mariabackup is a separate package in our repositories. On Debian and Ubuntu, it can be installed with (for 10.1):
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 Mariabackup
Mariabackup 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 Mariabackup for a SST with Galera Cluster, when Data-at-Rest encryption is used.
- Support of Microsoft Windows.
The command to use Mariabackup is
mariabackup <params>
Configuring Mariabackup
Since Mariabackup is based on Percona XtraBackup, it can be configured similarly. The username and password can be included in .cnf files:
[xtrabackup] user=myuser password=mypassword
Note that Mariabackup does not read options in the [mariadb] section of configuration files. Therefore, if a non-defult datadir is specified on a server, it must be specified in the [xtrabackup] or [mysqld] sections of configuration files for Mariabackup to be able to find the datadir and run correctly:
[mysqld] datadir=/var/mycustomdatadir
The Mariabackup user must have RELOAD, LOCK TABLES, and REPLICATION CLIENT privileges.
Using Mariabackup for Galera SSTs
In addition to the mariabackup utility, MariaDB Server installations also include the wsrep_sst_mariabackup shell script, which allows you to use Mariabackup to handle State Snapshot Transfers when the server operates as a node in Galera Cluster.
To use Mariabackup with SSTs, you must set the wsrep_sst_method and wsrep_sst_auth system variables.
[mysqld] ... wsrep_sst_method = mariabackup wsrep_sst_auth = user:password
This tells the node that you want to use the wsrep_sst_mariabackup script for State Snapshot Transfers and provides the authentication information it needs to access the other nodes in the cluster.
During the SST process, the donor node streams the backup to the joiner node. Then the joiner node prepares the backup before restoring it. Both the backup and prepare steps require Mariabackup, so you need to have it installed on both hosts. In addition to Mariabackup, you also need to have socat installed on the host. Mariabackup uses this utility to stream the backup from donor to joiner. It is a limitation Mariabackup inherits from the Xtrabackup version 2 SST method.
To secure the SST transfer using TLS, see
Granting Privileges for SSTs
The user set for the wsrep_sst_auth system variable need to have the RELOAD , PROCESS, LOCK TABLES and REPLICATION CLIENT privileges. You need to set these privileges for each node in your cluster on each node in your cluster. For instance, if your cluster has the IP addresses of 192.168.1.1, 192.168.1.2 and 192.168.1.3, on the first node you would run the following GRANT statements:
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_user'@'192.168.1.2'; GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backup_user'@'192.168.1.3';
This grants the user backup_user access to the first node from the second and third nodes. You can then issue the same GRANT statements on the second and third nodes, substituting their own IP addresses for that of the first node, ensuring that the backup user is able to operate across the cluster.
MyRocks Support in Mariabackup
Starting with MariaDB 10.2.16 and MariaDB 10.3.8, Mariabackup will back up MyRocks Storage Engine data. Partial backup of MyRocks data is currently not supported. Incremental backup will store a full copy of MyRocks data.
Versions
| Mariabackup/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 |
Limitations
MariaDB until 10.2.8
Before MariaDB 10.2.9, Mariabackup 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
mariabackupcreates an invalid (empty) redo-log-file,ib_logfile0as part of the prepare stage, to protect against wrong 'cp' commands. XtraBackup uses the file namextrabackup_logfile.
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.
