MariaDB Backup with mariabackup: Hot Backup Guide (2026)

MariaDB backups can be tricky, and mariabackup is the go-to tool for hot backups, but understanding its nuances is key to avoiding data loss.

Let’s see mariabackup in action. Imagine you have a database server with a few tables:

-- On your MariaDB server
CREATE DATABASE IF NOT EXISTS my_app;
USE my_app;
CREATE TABLE IF NOT EXISTS users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL
);
INSERT INTO users (username, email) VALUES ('alice', 'alice@example.com'), ('bob', 'bob@example.com');

Now, let’s perform a hot backup. We’ll need a directory to store the backup files.

# On your MariaDB backup host (can be the same as the server)
mkdir -p /mnt/backups/my_app_backup

The core mariabackup command looks like this:

mariabackup --backup --target-dir=/mnt/backups/my_app_backup --datadir=/var/lib/mysql

Here’s what’s happening:

--backup: This tells mariabackup to perform a backup operation.
--target-dir=/mnt/backups/my_app_backup: This is where the backup files will be written. mariabackup will create subdirectories here for the data files and logs.
--datadir=/var/lib/mysql: This is the crucial part – it points mariabackup to your MariaDB data directory. mariabackup needs to know where to find the actual database files.

After the command completes, you’ll have a directory structure like this:

/mnt/backups/my_app_backup/
├── 2023-10-27_10-30-00/  # Timestamped directory for the backup
│   ├── xtrabackup_checkpoints
│   ├── xtrabackup_info
│   ├── MY_APP/          # Subdirectory for your database
│   │   ├── users.frm
│   │   ├── users.ibd
│   │   └── ... (other table files)
│   └── ... (other database directories)
└── 2023-10-27_10-30-00.log # The log file from the backup

The xtrabackup_checkpoints file is essential; it contains metadata about the backup, including the LSN (Log Sequence Number) range covered. xtrabackup_info provides more details like the version of mariabackup used and the server version.

The real magic of a hot backup is that the database remains available for writes and reads during the backup process. mariabackup uses a technique similar to Percona XtraBackup (it’s derived from it) that streams data files while simultaneously logging any changes that occur. This ensures you get a consistent snapshot of your data at a specific point in time, even if transactions are ongoing.

To restore this backup, you’d typically prepare it first and then copy the files back.

# Prepare the backup
mariabackup --prepare --target-dir=/mnt/backups/my_app_backup/2023-10-27_10-30-00

# Stop your MariaDB server
systemctl stop mariadb

# Move existing data (or clear it out)
mv /var/lib/mysql /var/lib/mysql_old

# Copy prepared backup files to the data directory
mariabackup --copy-back --target-dir=/mnt/backups/my_app_backup/2023-10-27_10-30-00 --datadir=/var/lib/mysql

# Ensure correct permissions (important!)
chown -R mysql:mysql /var/lib/mysql

# Start your MariaDB server
systemctl start mariadb

The --prepare step applies the transaction logs to the data files to bring them to a consistent state. The --copy-back command then moves these prepared files into your MariaDB data directory.

One of the most powerful features, and often overlooked, is its ability to create incremental backups. After your initial full backup, you can take subsequent backups that only capture the changes since the last one. This significantly reduces backup time and storage space.

To do this, you’ll need the backupid from your previous full backup. You can find this in the xtrabackup_checkpoints file within your full backup’s timestamped directory. Let’s say your full backup was at /mnt/backups/my_app_backup/2023-10-27_10-30-00 and its backupid was 123456789.

# Create an incremental backup
mkdir -p /mnt/backups/my_app_incremental
mariabackup --backup --target-dir=/mnt/backups/my_app_incremental --datadir=/var/lib/mysql --incremental-from=123456789

The --incremental-from option tells mariabackup where to start copying changes from. Restoring an incremental backup involves preparing the full backup first, then applying each incremental backup in sequence.

The most surprising thing about mariabackup is how its --prepare stage works with incremental backups. When you prepare an incremental backup, it doesn’t just prepare itself; it implicitly prepares the entire chain of backups leading up to it, including the full backup. This means you don’t need to manually apply the full backup first; mariabackup figures out the necessary steps. This is why the --prepare command needs access to the full backup directory and potentially other incremental backups if they were taken after the one you’re preparing.

The next step you’ll encounter is understanding how to automate these backups and integrate them into a disaster recovery strategy.