阿里云rds mysql8.0 物理备份，恢复到本地服务器(Ubuntu 22.04.3 LTS (GNU/Linux 6.8.0-52-generic x86_64))

原创已于 2025-07-29 17:13:19 修改 · 1k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#linux #阿里云 #ubuntu #mysql

于 2025-03-14 11:46:41 首次发布

阿里云文档：RDS MySQL物理备份用XtraBackup恢复到自建数据库_云数据库 RDS(RDS)-阿里云帮助中心

主要踩坑：

1.安装备份恢复工具Percona XtraBackup

2.数据库启动权限问题

3.一定要准备大于：备份数据*2 的空余磁盘空间！！！

详细记录：

谨记：优先下载阿里云文档提供备份工具！！！工具不同会导致后续解包操作出现问题！！！

我一开始使用的是备份工具是参照这个地址安装的

地址：

Percona release and APT - Percona XtraBackup

但是安装后根据阿里文档操作，执行到恢复数据时出现问题

执行日志：

dlswtest@dlswtest-PowerEdge-R730xd:/var/dxdb$ /usr/bin/xtrabackup --defaults-file=/var/dxdb/dxsqldata/backup-my.cnf --prepare --target-dir=/var/dxdb/dxsqldata/ 2025-03-05T08:50:37.111619+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized server arguments: --innodb_checksum_algorithm=crc32 --innodb_log_checksums=1 --innodb_data_file_path=ibdata1:200M:autoextend --innodb_log_file_size=1048576000 --innodb_log_buffer_size=8388608 --innodb_page_size=16384 --innodb_undo_directory=./ --innodb_undo_tablespaces=2 --server-id=234775418 --innodb_log_checksums=ON --innodb_redo_log_encrypt=0 --innodb_undo_log_encrypt=0 2025-03-05T08:50:37.111810+08:00 0 [Note] [MY-011825] [Xtrabackup] recognized client arguments: --prepare=1 --target-dir=/var/dxdb/dxsqldata/ /usr/bin/xtrabackup version 8.0.35-32 based on MySQL server 8.0.35 Linux (x86_64) (revision id: c339924a) 2025-03-05T08:50:37.111860+08:00 0 [Note] [MY-011825] [Xtrabackup] cd to /var/dxdb/dxsqldata/ 2025-03-05T08:50:37.152931+08:00 0 [Note] [MY-011825] [Xtrabackup] This target seems to be not prepared yet. 2025-03-05T08:50:37.252585+08:00 0 [Note] [MY-011825] [Xtrabackup] xtrabackup_logfile detected: size=8388608, start_lsn=(30702030560905) 2025-03-05T08:50:37.254183+08:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration for recovery: 2025-03-05T08:50:37.254222+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = . 2025-03-05T08:50:37.254248+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:200M:autoextend 2025-03-05T08:50:37.267434+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = . 2025-03-05T08:50:37.267478+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 1 2025-03-05T08:50:37.267517+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 8388608 2025-03-05T08:50:37.275902+08:00 0 [Note] [MY-011825] [Xtrabackup] inititialize_service_handles suceeded 2025-03-05T08:50:37.286710+08:00 0 [Note] [MY-011825] [Xtrabackup] using the following InnoDB configuration for recovery: 2025-03-05T08:50:37.286753+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_home_dir = . 2025-03-05T08:50:37.286780+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_data_file_path = ibdata1:200M:autoextend 2025-03-05T08:50:37.286820+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_group_home_dir = . 2025-03-05T08:50:37.286841+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_files_in_group = 1 2025-03-05T08:50:37.286864+08:00 0 [Note] [MY-011825] [Xtrabackup] innodb_log_file_size = 8388608 2025-03-05T08:50:37.286900+08:00 0 [Note] [MY-011825] [Xtrabackup] Starting InnoDB instance for recovery. 2025-03-05T08:50:37.286922+08:00 0 [Note] [MY-011825] [Xtrabackup] Using 104857600 bytes for buffer pool (set by --use-memory parameter) 2025-03-05T08:50:37.286983+08:00 0 [Note] [MY-012932] [InnoDB] PUNCH HOLE support available 2025-03-05T08:50:37.287016+08:00 0 [Note] [MY-012944] [InnoDB] Uses event mutexes 2025-03-05T08:50:37.287037+08:00 0 [Note] [MY-012945] [InnoDB] GCC builtin __atomic_thread_fence() is used for memory barrier 2025-03-05T08:50:37.287058+08:00 0 [Note] [MY-012948] [InnoDB] Compressed tables use zlib 1.2.13 2025-03-05T08:50:37.301112+08:00 0 [Note] [MY-012951] [InnoDB] Using hardware accelerated crc32 and polynomial multiplication. 2025-03-05T08:50:37.301938+08:00 0 [Note] [MY-012203] [InnoDB] Directories to scan './' 2025-03-05T08:50:37.302022+08:00 0 [Note] [MY-012204] [InnoDB] Scanning './' 2025-03-05T08:50:38.239219+08:00 0 [Note] [MY-012208] [InnoDB] Completed space ID check of 164 files. 2025-03-05T08:50:38.251056+08:00 0 [Note] [MY-012955] [InnoDB] Initializing buffer pool, total size = 128.000000M, instances = 1, chunk size =128.000000M 2025-03-05T08:50:38.272060+08:00 0 [Note] [MY-012957] [InnoDB] Completed initialization of buffer pool 2025-03-05T08:50:38.277947+08:00 0 [ERROR] [MY-012592] [InnoDB] Operating system error number 2 in a file operation. 2025-03-05T08:50:38.277989+08:00 0 [ERROR] [MY-012593] [InnoDB] The error means the system cannot find the path specified. 2025-03-05T08:50:38.278006+08:00 0 [ERROR] [MY-012594] [InnoDB] If you are installing InnoDB, remember that you must create directories yourself, InnoDB does not create them. 2025-03-05T08:50:38.278022+08:00 0 [ERROR] [MY-012646] [InnoDB] File ./ibdata1: 'open' returned OS error 71. Cannot continue operation 2025-03-05T08:50:38.278214+08:00 0 [ERROR] [MY-012981] [InnoDB] Cannot continue operation.

经过反复测试，最终判断是XtraBackup工具问题！！！缺少工具：xtrabackupex 无法正常执行

果断卸载之前的工具，重新安装，工具开源地址：Software Downloads - Percona

执行到启动数据库步骤时出现第二个坑

异常信息：

判断 MySQL 服务在尝试访问或创建 binlog.index 文件时被操作系统拒绝了权限。以下是可能的原因及解决方法：
1.文件系统权限不足 MySQL 用户（通常是 mysql）没有对数据目录或相关文件的读写权限。
2.SELinux 或 AppArmor 配置限制如果启用了 SELinux 或 AppArmor，可能会限制 MySQL 对某些文件或目录的访问。
3.目录或文件被其他进程占用其他进程可能锁定了该文件，导致 MySQL 无法访问。
4.数据目录路径配置错误 MySQL 的数据目录配置可能与实际路径不一致，导致无法找到文件。

确保 MySQL 数据目录及其子文件夹和文件的权限正确：

sudo chown -R mysql:mysql /var/mysql_newdata
sudo chmod -R 750 /var/mysql_newdata

检查 SELinux，SELinux状态是关闭的。

随后又再次确认磁盘空余及数据目录配置，都是正确的。

纳闷了到底什么问题呢，网上查了很多都不管用，看错误日志判断还是权限或者安全问题

就想起来AppArmor这个还没确认，因为一开始查了SElinux 是关闭的，现在想想，操作系统是 ubuntn ，还是查一下，结果就找到问题了

检查 AppArmor 状态： sudo aa-status
查看 AppArmor 是否启用了对 MySQL 的限制：
sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
sudo systemctl restart apparmor

随后把这个 /usr/sbin/mysqld 给关了，数据库就可以启动成功了！！！