Restore MariaDB from a mariabackup Backup

To restore MariaDB from a mariabackup backup you prepare the backup files, move the current data directory aside, copy the prepared files back with mariabackup --copy-back, fix ownership and start the server. This guide walks through the whole procedure on a Linux VPS, including incremental backups and the errors you are most likely to hit.

A mariabackup restore is a full-instance restore. It replaces every database on the server with the state captured in the backup. If you only need one database back, use a logical dump instead — see restore a MySQL database from a mysqldump file.

Before you start

You need:

• Root or sudo access to the VPS, and a working SSH session. If you are not connected yet, follow connect to your Linux VPS with SSH.
• A mariabackup backup directory, for example /var/backups/mariadb/full. A full backup contains xtrabackup_checkpoints, ibdata1, mysql/ and one directory per database.
• The same MariaDB major version as the server that produced the backup. mariabackup is version-sensitive; check the vendor's documentation if you are moving between major releases.
• Free disk space at least equal to the size of the backup plus the current data directory, because you will keep the old directory until you are sure the restore worked.

Confirm the data directory path first, because some installs use /var/lib/mysql and others use a custom path:

mysql -e "SELECT @@datadir, @@version;"

Note the version string. It should match the version that created the backup.

Stop MariaDB and move the old data directory

Stop the service and make sure nothing is holding the data directory open:

sudo systemctl stop mariadb
sudo systemctl status mariadb

The status output should say inactive (dead). Then move the current data directory out of the way and create an empty one:

sudo mv /var/lib/mysql /var/lib/mysql.old.$(date +%F)
sudo mkdir -p /var/lib/mysql

mariabackup --copy-back refuses to write into a directory that already contains data, so this step is not optional.

Prepare the mariabackup files

A mariabackup backup is not usable until it has been prepared. Preparation applies the redo log so the InnoDB tables are consistent and the server can open them.

sudo mariabackup --prepare --target-dir=/var/backups/mariadb/full

You will see a long stream of InnoDB output. The last line should look like:

[00] 2026-01-01 10:14:02 completed OK!

If you also have incremental backups, prepare the base first, then each increment in order:

sudo mariabackup --prepare --target-dir=/var/backups/mariadb/full
sudo mariabackup --prepare --target-dir=/var/backups/mariadb/full \
  --incremental-dir=/var/backups/mariadb/inc1

Restore MariaDB from the prepared backup

With the data directory empty and the backup prepared, copy the files back:

sudo mariabackup --copy-back \
  --target-dir=/var/backups/mariadb/full \
  --datadir=/var/lib/mysql

If the backup lives on the same filesystem and you do not need to keep it, --move-back is faster because it renames files instead of copying them:

sudo mariabackup --move-back --target-dir=/var/backups/mariadb/full --datadir=/var/lib/mysql

Either way, the command ends with completed OK!. If it stops with a permissions error, check that you ran it with sudo.

Fix ownership and start MariaDB

The copied files belong to root. MariaDB runs as the mysql user and will not start until ownership is corrected:

sudo chown -R mysql:mysql /var/lib/mysql
sudo find /var/lib/mysql -type d -exec chmod 750 {} \;
sudo find /var/lib/mysql -type f -exec chmod 640 {} \;

Start the service and watch the log:

sudo systemctl start mariadb
sudo systemctl status mariadb
sudo tail -n 50 /var/log/mysql/error.log

On Debian and Ubuntu the error log may be at /var/log/mysql/error.log; on AlmaLinux and Rocky it is usually /var/log/mariadb/mariadb.log. If the service is active (running) and the log shows Ready for connections, the restore worked.

Check it works

Connect and confirm the data is what you expect:

mysql -e "SHOW DATABASES;"
mysql -e "SELECT user, host FROM mysql.user;"
mysql -e "SELECT COUNT(*) FROM your_app_db.orders;"

Check that the application databases are present, that the user accounts are back, and that a table you know returns a sensible row count. Then open the site or application and log in. Once you are satisfied, keep the old directory for a few days before deleting it:

sudo du -sh /var/lib/mysql.old.*

Troubleshooting

• mariabackup: error: cannot open./xtrabackup_checkpoints — you pointed --target-dir at the wrong folder, or the backup was never completed. Check the path and that the file exists.
• --copy-back fails with "data directory is not empty" — the target still contains files. Move /var/lib/mysql aside again and recreate it empty before retrying.
• MariaDB will not start, log shows Permission denied on ibdata1 — ownership was not fixed. Re-run the chown -R mysql:mysql /var/lib/mysql step.
• Log shows Unsupported redo log format or an InnoDB version error — the mariabackup binary and the MariaDB server version do not match the backup. Install the matching version, or restore into a server of the same major release.
• Server starts but tables are missing — you restored an incremental backup without preparing the base first, or you copied the wrong target directory. Re-run the prepare step in the correct order.

Next steps

• Need a single database rather than the whole instance? Use restore a MySQL database from a mysqldump file.
• Set up regular logical dumps alongside your physical backups with back up and restore MySQL databases with mysqldump.
• If the server was compromised before the restore, read incident response: preserving forensic evidence from a compromised Linux server before you overwrite anything.
• Check that the restored instance has enough memory for its workload with tune MySQL and MariaDB memory settings for a small VPS.