This topic describes how to use Percona XtraBackup to restore the data of an ApsaraDB RDS for MySQL instance from a physical backup file to a self-managed MySQL database.
Background information
ApsaraDB RDS for MySQL allows you to restore the data of an RDS instance from backup files to a self-managed database. Various restoration methods, such as restoration from physical backup files and restoration from logical backup files, are supported. For more information about how to select a data restoration method, see Overview of data restoration methods.
You can perform the following operations to check the backup method of your RDS instance: Log on to the ApsaraDB RDS console and go to the details page of your RDS instance. In the left-side navigation pane of the instance details page, click Backup and Restoration. On the page that appears, choose Base Backups > Data Backup.
If no physical backup files are created, you can manually create a physical backup file before you perform the operations that are described in this topic. For more information, see Manually back up an ApsaraDB RDS for MySQL instance.
Scenarios
The procedure described in this topic is not aplicable to scenarios where you need to restore a downloaded physical backup file to a new ApsaraDB RDS for MySQL instance. To perform this type of restoration, you can follow the steps described in this topic to restore the physical backup file to a self-managed MySQL database first, and then restore the data in the self-managed MySQL database to a new ApsaraDB RDS for MySQL instance referring to Restore the backup data of a self-managed instance that runs MySQL 5.7 or MySQL 8.0 to an ApsaraDB RDS for MySQL instance.
If you do not use your RDS instance for a long period of time in the future, you can restore the data of your RDS instance from a physical backup file to a self-managed MySQL database. This way, the data of your RDS instance can be retained.
If your RDS instance is released and cannot be retrieved but you downloaded a physical backup file of the instance, you can restore the data of your RDS instance from the physical backup file to a self-managed MySQL database.
Prerequisites
Your RDS instance meets the following requirements:
The RDS instance runs MySQL 8.0, MySQL 5.7, MySQL 5.6, or MySQL 5.5.
The RDS instance runs RDS High-availability Edition.
The RDS instance uses local disks.
NoteYou can go to the Basic Information page of your RDS instance to obtain the preceding information.
Physical backup files can be downloaded only when RDS instances run RDS High-availability Edition. If your RDS instance runs RDS Basic Edition, you can restore the data of the RDS instance based on the instructions provided in Other FAQ.
Tables in the RDS instance are not encrypted by using Transparent Data Encryption (TDE). For more information, see Configure TDE.
ImportantIf some tables are encrypted by using TDE, errors occur during the restoration. Before you download the backup files of the RDS instance, you must decrypt the encrypted tables. For more information, see Configure TDE.
You can perform the following operations to check whether TDE is enabled: Go the Data Security page of your RDS instance. Then, click the TDE tab.
The RAM user that you use to log on to your RDS instance is granted the permissions to download backup files. For more information about how to grant permissions to a RAM user, see Grant backup file download permissions to a RAM user with read-only permissions.
Limits
The restoration method described in this topic is suitable only for RDS instances that use local disks. If you want to use the snapshot backup files to restore the data of an RDS instance that uses cloud disks, follow the instructions provided in Restore the data of an ApsaraDB RDS for MySQL instance to a self-managed MySQL instance by using snapshot backup files.
The restoration method described in this topic restores full data in a backup file. If you want to restore the data of only specific databases and tables, follow the instructions provided in Restore the data of an ApsaraDB RDS for MySQL instance from a logical backup file to a self-managed MySQL instance.
You can restore the data of an RDS instance from a physical backup file only to a self-managed MySQL database that runs on Linux.
This solution is not suitable for data restoration for RDS clusters that use the MySQL group replication (MGR) mode.
Impacts
If other services are running in your self-managed MySQL database, the services become unavailable after you restore the data of your RDS instance from a physical backup file to the self-managed MySQL database.
The restoration method described in this topic is used to restore the data of your RDS instance to a new data directory in your self-managed MySQL database. This does not affect the original data in the self-managed database.
Implementation
The sections describes the steps that you must perform to restore data from a physical backup file:
Perform a full physical backup on your RDS instance in the ApsaraDB RDS console.
Download the physical backup file to your computer and use the
qpress
tool to decompress the file.Use
Percona XtraBackup
to restore the data to a data directory of your self-managed MySQL database from the decompressed backup file.Restart your self-managed MySQL database. Then, you can view the data of your RDS instance in the self-managed MySQL database.
Usage notes
A download URL is valid only for 1 hour after it is generated. If a download URL expires, you can refresh the page to obtain the latest download URL.
We recommend that you do not modify or delete a physical backup file. If you modify or delete a physical backup file, the file may be damaged and cannot be restored. If you need to modify a physical backup file of an RDS instance, we recommend that you restore the data of the RDS instance from the physical backup file to your self-managed MySQL database and then modify the file.
Billing rules
If you need to perform manual backups, take note of the backup storage that is used to store the manual backup files. If the backup storage usage exceeds the free quota, you are charged for the excess backup storage that you use. For more information, see Backup storage fees.
If your self-managed MySQL database is deployed on your on-premises machine, you must download backup files over the Internet. If the traffic that is generated when you download the backup files exceeds the free quota, you are charged for the excess Internet traffic. For more information, see Download backup files.
NoteIf your self-managed MySQL database is deployed on an Elastic Compute Service (ECS) instance that resides in the same region and virtual private cloud (VPC) as your RDS instance, you can download backup files over an internal network. In this case, no traffic fees are generated.
Preparations
Environment preparation
Tool preparation
Step 1: Download a backup file
Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the instance ID.
In the left-side navigation pane, click Backup and Restoration.
On the page that appears, choose Base Backups > Data Backup. Find the physical backup file that you want to download and click Download Instance Backup in the Actions column.
If no physical backup files are available, you can perform a manual backup to create a physical backup file. For more information, see Manually back up an ApsaraDB RDS for MySQL instance.
If the Advanced Download page appears after you click Download Instance Backup, your RDS instance uses cloud disks, and you can restore the data of the RDS instance only based on the instructions provided in Restore the data of an ApsaraDB RDS for MySQL instance to a self-managed MySQL instance by using snapshot backup files.
In the Download Instance Backup Set dialog box, click the icon next to Internal URL or Public URL.
ImportantIf you use an internal URL to download the backup file, make sure that the server to which you log on and the RDS instance reside in the same VPC. If the server and the RDS instance reside in cross-region VPCs or if the server resides in the classic network and the RDS instance resides in a VPC, you cannot download the backup file by using the internal URL.
If you use the external URL to download the backup file, you are charged for the excess Internet traffic that you consume. For more information, see Billing rules.
A download URL is valid only for 1 hour after it is generated. If a download URL expires, you can refresh the page to obtain the latest download URL.
We recommend that you do not modify or delete the physical backup file. If you modify or delete the physical backup file, the file may be damaged and cannot be restored. If you need to modify the physical backup file, we recommend that you restore the data of the RDS instance from the physical backup file to the self-managed MySQL database and then modify the file.
Log on to the Linux server on which your self-managed MySQL database resides and run the following command to download the physical backup file:
wget -c 'https://****.bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qp
NoteReplace
https://****.bak.rds.aliyuncs.com/****_xb.qp?****
in the command with the download URL that you copied. After you download the backup file, save it and keep it confidential.test_xb.qp
specifies the new name of the file that you want to save. You can specify a custom file name, but the file name extension must be the same as the file name extension in the download URL.Starting January 20, 2021, the file name extension of a physical backup file in ApsaraDB RDS for MySQL is changed to
_xb.qp
. If the file name extension of your physical backup file is_qp.xb
, you must also use_qp.xb
as the file name extension of the file. You can view the file name extension of the backup file in the download link. For more information, see [Product changes/Feature changes] New physical backup file format is phased in for some ApsaraDB RDS for MySQL instances.If your RDS instance runs MySQL 5.5, the file name extension of the physical backup file is
tar.gz
.
FAQ about file downloads
Step 2: Decompress the backup file
Run the following command to decompress the backup file:
Before you run the command, make sure that
Percona XtraBackup
andqpress
are installed on the server on which your self-managed MySQL database resides. For more information, see Preparations. If you do not install the tools, the decompression command cannot be run.When you run the command, replace
test_xb.qp
with the name of the backup file that you saved and replace/var/mysql_bkdata/
with the backup decompression directory that you created.
### MySQL 8.0
qpress -do test_xb.qp | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/
### MySQL 5.5/5.6/5.7
qpress -do test_xb.qp | xbstream -x -v -C /var/mysql_bkdata/
If the file name extension of the backup file is not _xb.qp, use one of the following methods to decompress the backup file:
FAQ about decompression
Step 3: Restore data
Before you restore data to your self-managed MySQL database, stop the database.
You can run the ps -ef | grep '[m]ysql'
command to check whether MySQL
-related processes exist. If MySQL-related processes exist, you can run the sudo kill -9 <PID>
command to terminate the processes.
Restore the data of an RDS instance that runs MySQL 8.0
Prepare for the restoration.
/u01/xtrabackup80/bin/xtrabackup --defaults-file=/var/mysql_bkdata/backup-my.cnf --prepare --target-dir=/var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the configuration file that contains default MySQL settings.
After the physical backup file is decompressed, a file named
backup-my.cnf
is obtained and is stored in the backup decompression directory, which is/var/mysql_bkdata/
in this example.--prepare
The command that is used to prepare Percona XtraBackup.
--target-dir
The backup decompression directory, which is
/var/mysql_bkdata/
in this example.Modify the datadir parameter of the self-managed MySQL database.
Modify the configuration file of the database.
sudo vim /etc/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and change the value of the datadir parameter to/var/mysql_newdata
.datadir = /var/mysql_newdata
mysql_newdata
specifies the new data directory of your self-managed MySQL database. For more information, see Preparations.Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Restore data.
sudo xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the
my.cnf
file. You can obtain the data directory to which the data is restored from the datadir parameter in the configuration file.--copy-back
The restoration command that is run by Percona XtraBackup.
--target-dir
The backup decompression directory, which is
/var/mysql_bkdata/
in this example. Percona XtraBackup restores the data in this directory to the data directory of the self-managed MySQL database.
Restore the data of an RDS instance that runs MySQL 5.7
Prepare for the restoration.
innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the configuration file that contains default MySQL settings.
After the physical backup file is decompressed, a file named
backup-my.cnf
is obtained and is stored in the backup decompression directory, which is/var/mysql_bkdata/
in this example.--apply-log
The command that is used to prepare Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. The backup decompression directory stores the backup file.Modify the
my.cnf
configuration file of the self-managed MySQL database.Modify the configuration file of the database.
sudo vim /etc/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and change the value of the datadir parameter to/var/mysql_newdata
.datadir = /var/mysql_newdata
mysql_newdata
specifies the new data directory of your self-managed MySQL database. For more information, see Preparations.Add the following content to the
my.cnf
file:innodb_undo_tablespaces=2 innodb_undo_directory=/var/mysql_newdata
ImportantThe value of the innodb_undo_tablespaces parameter must be the same as the value in the
/var/mysql_bkdata/backup-my.cnf
file. You can run thecat /var/mysql_bkdata/backup-my.cnf | grep innodb_undo_tablespaces
command to query the value.Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Restore data.
sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the
my.cnf
file. You can obtain the data directory to which the data is restored from the datadir parameter in the configuration file.--copy-back
The restoration command that is run by Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. Percona XtraBackup restores the data in the directory to the data directory of the self-managed MySQL database.
Restore the data of an RDS instance that runs MySQL 5.6
Prepare for the restoration.
innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the configuration file that contains default MySQL settings.
After the physical backup file is decompressed, a file named
backup-my.cnf
is obtained and is stored in the backup decompression directory, which is/var/mysql_bkdata/
in this example.--apply-log
The command that is used to prepare Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. The backup decompression directory stores the backup file.Modify the datadir parameter of the self-managed MySQL database.
Modify the configuration file of the database.
sudo vim /usr/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and add the datadir parameter setting.datadir = /var/mysql_newdata
mysql_newdata
specifies the new data directory of your self-managed MySQL database. For more information, see Preparations.Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Restore data.
sudo innobackupex --defaults-file=/usr/my.cnf --copy-back /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the
my.cnf
file. You can obtain the data directory to which the data is restored from the datadir parameter in the configuration file.--copy-back
The restoration command that is run by Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. Percona XtraBackup restores the data in the directory to the data directory of the self-managed MySQL database.
Restore the data of an RDS instance that runs MySQL 5.5
Prepare for the restoration.
innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the configuration file that contains default MySQL settings.
After the physical backup file is decompressed, a file named
backup-my.cnf
is obtained and is stored in the backup decompression directory, which is/var/mysql_bkdata/
in this example.--apply-log
The command that is used to prepare Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. The backup decompression directory stores the backup file.Modify the
my.cnf
configuration file of the self-managed MySQL database.Modify the configuration file of the database.
sudo vim /etc/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and add the datadir parameter setting.datadir = /var/mysql_newdata
mysql_newdata
specifies the new data directory of your self-managed MySQL database. For more information, see Preparations.Add the following content to the
my.cnf
file:innodb_log_file_size=1048576000
ImportantThe value of the innodb_log_file_size parameter must be the same as the value in the
/var/mysql_bkdata/backup-my.cnf
file. You can run thecat /var/mysql_bkdata/backup-my.cnf | grep innodb_log_file_size
command to query the value.Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Restore data.
sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/
Parameters
Parameter
Description
--defaults-file
The directory of the
my.cnf
file. You can obtain the data directory to which the data is restored from the datadir parameter in the configuration file.--copy-back
The restoration command that is run by Percona XtraBackup.
This parameter is followed by the backup decompression directory, which is
/var/mysql_bkdata/
in this example. Percona XtraBackup restores the data in the directory to the data directory of the self-managed MySQL database.
FAQ about data restoration
Step 4: Start the database
MySQL 8.0 or MySQL 5.7
Optional. Log on to the ApsaraDB RDS console and view the value of the lower_case_table_names parameter based on the instructions provided in View the parameters of an ApsaraDB RDS for MySQL instance. If the value is
1
, you must modify themy.cnf
configuration file of the self-managed MySQL database.Modify the configuration file of the database.
sudo vim /etc/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and add the following content to the file:lower_case_table_names=1
Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Grant permissions on the data directory.
sudo chown -R mysql:mysql /var/mysql_newdata
Run the following command to start the MySQL process:
sudo mysqld --defaults-file=/etc/my.cnf --user=mysql --datadir=/var/mysql_newdata &
Parameters
Parameter
Description
--defaults-file
The directory of the configuration file of the self-managed MySQL database. In this example,
/etc/my.cnf
is used. You can obtain the directory of the configuration file based on the Preparations section.--user
The user who started the database. The value is fixed as mysql.
--datadir
The data directory that is used to start the database. In this example,
/var/mysql_newdata
is used. You can obtain the data directory based on the Preparations section.
MySQL 5.6
Optional. Log on to the ApsaraDB RDS console and view the value of the lower_case_table_names parameter based on the instructions provided in View the parameters of an ApsaraDB RDS for MySQL instance. If the value is
1
, you must modify themy.cnf
configuration file of the self-managed MySQL database.Modify the configuration file of the database.
sudo vim /usr/my.cnf
For more information about how to query the directory of the configuration file, see Preparations.
Press
i
to enter the insert mode and add the following content to the file:lower_case_table_names=1
Press the
Esc
key to exit the edit mode, and enter:wq
to save the file and exit.
Grant permissions on the data directory.
sudo chown -R mysql:mysql /var/mysql_newdata
Run the following command to start the MySQL process:
sudo mysqld --defaults-file=/usr/my.cnf --user=mysql --datadir=/var/mysql_newdata &
Parameter
Description
--defaults-file
The directory of the configuration file of the self-managed MySQL database. In this example,
/usr/my.cnf
is used. You can obtain the directory of the configuration file based on the Preparations section.--user
The user who started the database. The value is fixed as mysql.
--datadir
The data directory that is used to start the database. In this example,
/var/mysql_newdata
is used. You can obtain the data directory based on the Preparations section.
MySQL 5.5
Grant permissions on the data directory.
sudo chown -R mysql:mysql /var/mysql_newdata
Run the following command to start the MySQL process:
sudo mysqld --defaults-file=/etc/my.cnf --user=mysql --datadir=/var/mysql_newdata &
Parameter
Description
--defaults-file
The directory of the configuration file of the self-managed MySQL database. In this example,
/etc/my.cnf
is used. You can obtain the directory of the configuration file based on the Preparations section.--user
The user who started the database. The value is fixed as mysql.
--datadir
The data directory that is used to start the database. In this example,
/var/mysql_newdata
is used. You can obtain the data directory based on the Preparations section.
FAQ about startup
Step 5: Connect to the database and verify the restoration
Run the following command to log on to the self-managed MySQL database and verify that MySQL is running:
mysql -u<The username of the account that is used to connect to the RDS instance> -p<The password of the preceding account>
NoteThe command is used to check whether the restoration is successful. If you only want to query data in a table, you can use an account that has permissions on the table to run the command. You do not need to use a privileged account.
You can also use a third-party tool, client, or command line to connect to the database. For more information, see Use a database client or the CLI to connect to an ApsaraDB RDS for MySQL instance.
Execute the following SQL statement to check whether a database in the RDS instance exists:
SHOW DATABASES;
FAQ about connection and verification
What to do next
For more information about how to use the backup files of an RDS instance to restore the full data or individual databases and tables of the RDS instance to another RDS instance or a new RDS instance, see Restore full data or Restore individual databases and tables.
For more information about data restoration methods, see Overview of data restoration methods.