Restoring Your MySQL/Percona Server with a Full XtraBackup

Disaster strikes, data loss occurs, or perhaps you're just migrating to new hardware. Whatever the reason, knowing how to confidently restore your database from a full backup is a critical skill for any system administrator or developer. Percona XtraBackup is the industry-standard tool for hot, non-blocking backups of MySQL and Percona Server, and its restore process is robust and reliable.

This guide will walk you through the steps to restore a full XtraBackup to a new MySQL/Percona Server instance.

Understanding the XtraBackup Restore Process

Unlike a mysqldump file that you simply import, Percona XtraBackup creates a physical backup – a copy of your raw data files. This makes backups very fast, but it requires a specific "preparation" phase before the files can be used by a new database server.

The process essentially involves:

1. Preparation: Making the raw backup files consistent.
2. Copy-back: Moving the prepared files to the new server's data directory.
3. Permissions: Adjusting file ownership.
4. Startup: Bringing the new database server online.

Step-by-Step Restore Guide

Let's assume you have a full backup located in a directory, for example, /path/to/your/full_backup_dir.

Step 1: Install Percona Server and XtraBackup

On your target machine (the server where you want to restore the data), ensure you have Percona Server for MySQL and Percona XtraBackup installed. Always aim for a matching major version (e.g., if your backup is from MySQL 8.0, restore to Percona Server 8.0).

On Rocky Linux / CentOS / RHEL:

# Install Percona repository
sudo dnf install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

# Enable 8.0 repos (adjust for your MySQL version if different)
sudo percona-release setup ps80
sudo percona-release setup pxb-80

# Disable default MySQL module (if applicable)
sudo dnf module disable -y mysql

# Install Percona Server and XtraBackup
sudo dnf install -y percona-server-server percona-xtrabackup-80

Step 2: Stop the MySQL Service

If Percona Server started automatically after installation, you must stop it. A restore needs an inactive data directory.

sudo systemctl stop mysqld

Step 3: Clean the Data Directory

The restore process requires the target data directory (default /var/lib/mysql) to be empty before copying files.

⚠️ WARNING: This command permanently deletes everything in the specified directory. Double-check your path!

sudo rm -rf /var/lib/mysql/*

Step 4: Decompress the Backup (If Compressed)

If your backup was taken with the --compress option, you must decompress it first. You'll know if your files end with .lz4, .qpress, or other compression extensions.

# Example for LZ4 compression
sudo xtrabackup --decompress --parallel=4 --target-dir=/path/to/your/full_backup_dir

Replace 4 with the number of CPU cores you want to use for decompression.

Step 5: Prepare the Backup

This is the crucial step where XtraBackup performs a "crash recovery" on your backup files, making them consistent and ready for use.

sudo xtrabackup --prepare --target-dir=/path/to/your/full_backup_dir

You should see output ending with ...completed OK! indicating success.

Step 6: Copy the Prepared Files

Now, copy the consistent files from your backup directory into the server's empty data directory.

sudo xtrabackup --copy-back \
  --target-dir=/path/to/your/full_backup_dir \
  --datadir=/var/lib/mysql

Step 7: Adjust File Permissions

Files copied by xtrabackup will be owned by the root user. MySQL needs them to be owned by the mysql user. This step is critical for the server to start successfully.

sudo chown -R mysql:mysql /var/lib/mysql

Step 8: Start the MySQL Service

Finally, start your Percona Server. It will now boot up using the data you've restored.

sudo systemctl start mysqld

Verify its status:

sudo systemctl status mysqld

You should see it active and running. You can now connect to your database using the credentials that existed in your original backup.

Conclusion

Restoring a full Percona XtraBackup is a systematic process. By following these steps carefully, you can efficiently recover your database, minimizing downtime and ensuring data integrity. Regular practice of your restore procedure is highly recommended to build confidence and refine your disaster recovery plan.