离线安装 percona-xtrabackup-24 这个需求通常出现在内网数据库集群、隔离机房或者没有外网权限的服务器上。明明在可联网的机器上几分钟就能装好的备份工具一旦换成离线环境很多人就卡在“包拷进去了命令却跑不起来”这一步。我前阵子做 MySQL 5.7 数据迁移时就因为在下载依赖时少拉了一个libev.so.4在离线服务器上折腾了大半天最后用ldd才定位到问题。这篇文章把完整流程写出来版本怎么选、依赖怎么下载、RPM / deb / tar 包怎么装、装完怎么验证以及第一次备份前容易踩的权限坑适合运维、DBA 和刚接触 XtraBackup 的开发者直接参考。1. 离线安装前先定版本2.4 系列和你的 MySQL 版本必须匹配1.1 2.4 为什么是 MySQL 5.6 / 5.7 环境里的安全牌Percona XtraBackup 2.4 并不是“比 8.0 更旧”的版本而是面向 MySQL 5.6、5.7 的对应版本。它和 MySQL 8.0 使用的 Percona XtraBackup 8.x 是两套独立工具链核心区别在于 redo log 格式、数据页校验和机制以及对新版本 MySQL 特性的支持。如果在 MySQL 5.7 实例上误用了 XtraBackup 8.0 的二进制备份阶段可能还能跑一段但 prepare 或恢复阶段大概率会碰到 redo log 不兼容的报错。这个错误在离线环境里非常致命因为你想临时换一个正确版本的包还得重新走一遍下载、传输、依赖验证的流程。因此我建议离线环境的目标机器如果是下面这种版本组合数据库版本推荐 XtraBackup 版本说明MySQL 5.6 / 5.7XtraBackup 2.4 系列工具链匹配度最高MySQL 8.0 / 8.4XtraBackup 8.x 系列直接使用 8.0 对应版本MariaDB 大部分版本需单独评估部分场景下需要看特定兼容性提示离线部署时不要单纯追求“下载最新 XtraBackup”要先把目标 MySQL 版本号确认清楚再确定下载 2.4 或 8.x。1.2 二进制包与发行版、glibc 的匹配关系同一个 XtraBackup 2.4针对不同 Linux 发行版有不同的包名。比如 CentOS 7 上常见的percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm其中的el7就是发行版标识Ubuntu 18.04 / 20.04 上则是bionic、focal后缀的.deb包此外还有面向通用 Linux 的glibc2.12tar 包。这些二进制不是简单的“x86_64 就能通用”。编译时链接的 glibc、OpenSSL、libcurl 等动态库版本不同跨发行版使用很容易出现找不到共享库的报错。离线环境最常见的翻车场景就是有人把 CentOS 8 的 el8 rpm 包拷到 CentOS 7 机器上rpm -ivh时提示依赖冲突或者干脆直接解压 tar 包一跑xtrabackup --version系统提示缺少某个GLIBC_2.28符号。注意在下载阶段就要把包名完整保留并把“目标操作系统版本、架构、XtraBackup 小版本号”一起记下来。这是离线安装最容易被忽略但最值得先做的一步。2. 在可联网机器上把依赖链一次性拉全离线最难的是这一步2.1 yumdownloader 与 downloadonlyRPM 系的一键拉包对 CentOS / RHEL 系统我会先准备一台和离线目标相同大版本、同样架构的机器然后使用yumdownloader把软件包和依赖全部拉下来yum install -y yum-utils mkdir -p /tmp/pxb24 yumdownloader --resolve --destdir/tmp/pxb24 percona-xtrabackup-24这里的--resolve参数非常关键。它会自动解析并下载一切需要的依赖不只是主程序本身。最终/tmp/pxb24目录里会留下一堆rpm包比如percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm、libev-4.15-7.el7.x86_64.rpm、libaio-0.3.109-13.el7.x86_64.rpm、numactl-libs-2.0.12-5.el7.x86_64.rpm等等。如果系统里没有yumdownloader还可以用另一种方式yum install --downloadonly --downloaddir/tmp/pxb24 percona-xtrabackup-24两种方式效果类似我个人更常用yumdownloader --resolve因为输出更清晰也不会真的把包安装到本机避免污染这台下载机器自身的环境。注意在联网机器上执行前要先配置好 Percona 官方软件源或者把之前已经下载好的 Percona rpm 包放到一个本地目录中作为安装源。2.2 apt-get download 与依赖解析deb 系容易漏包Debian / Ubuntu 上的离线下载稍微麻烦一点。apt-get download只会下载指定的软件包不会自动拉依赖。所以你需要先看依赖关系再逐个下载apt-get update apt-get download percona-xtrabackup-24 apt-cache depends percona-xtrabackup-24更省事的做法是使用apt-get install --download-only --no-install-recommends percona-xtrabackup-24这个命令会把主包以及依赖.deb都缓存在/var/cache/apt/archives目录里之后直接把目录中的所有.deb文件一起拷到离线机器即可。需要注意不要把在线机器上所有缓存的.deb一股脑复制进目标机器再用dpkg -i暴力安装。有些包目标机器可能已经有更新版本强行覆盖反而会把系统环境搞乱。按需选择依赖更稳妥。2.3 常见缺库报错和对应依赖清单离线安装中卡住大家的其实大多是动态库问题。我把几个常见报错列出来方便安装失败时快速对照典型报错信息大概率缺的依赖RPM 系列包名参考error while loading shared libraries: libev.so.4libevlibeverror while loading shared libraries: libaio.so.1libaiolibaioCant locate DBD/mysql.pmPerl MySQL 驱动perl-DBD-MySQLCant locate DBI.pmPerl DBI 模块perl-DBIerror while loading shared libraries: libnuma.so.1NUMA 库numactl-libserror while loading shared libraries: libcurl.so.4curl 运行库libcurl这些依赖在离线机器的系统安装光盘、系统镜像或内网软件源里一般都能找到。优先用系统自带的软件仓库补装而不是去第三方网站下载否则又会引入新的版本兼容问题。3. 三种离线安装法RPM、deb、免安装 tarball 的实操差异3.1 RPM 系使用 yum localinstall 而不是 rpm -ivh把/tmp/pxb24下的 rpm 包传到离线服务器后我一般首选yum localinstall -y /tmp/pxb24/*.rpm如果目标机器是 CentOS 8 或更新的发行版命令可以写成dnf localinstall -y /tmp/pxb24/*.rpmyum localinstall的本质是把本地目录当作一个临时软件源可以在当前目录中解析依赖关系。只要/tmp/pxb24里的包是完整的就能一次性装完。rpm -ivh是备用方案不过它不会自动解析依赖一旦缺少某个依赖就只输出一句“Failed dependencies”然后你看半天也不知道该去哪个仓库找。更不要用rpm -ivh --nodeps强行绕过依赖结果往往是rpm -qa能查到包但一执行xtrabackup --version系统直接报缺库。这种情况在离线环境里很难补救因为报错信息会指向某个具体的.so文件你还得回到联网机器去搜索对应版本。3.2 deb 系使用 dpkg -i 时的补依赖顺序deb 系离线安装常规做法是把下载好的.deb文件放到目标目录然后dpkg -i /tmp/pxb24/percona-xtrabackup-24*.deb如果报出dependency problems先别慌。看一下具体提示缺什么再从联网机器上下载对应的.deb传输进来后再执行一次dpkg -i /tmp/pxb24/*.deb必要的时候配合apt-get install -f但这个命令在离线环境里通常会因为没有外网而失败所以最可靠的方法还是把依赖.deb都补齐后再安装。不建议用dpkg --force-depends -i强行忽略依赖。这样虽然包能装上但下次运行xtrabackup时很可能因为缺少动态库而报错到时候排查起来比一开始就补全依赖要麻烦得多。3.3 tar.gz 解压方式软链和 PATH 配置除了 rpm 和 debXtraBackup 2.4 官方还提供免安装的 tar.gz 包比如percona-xtrabackup-2.4.28-linux-x86_64.glibc2.12.tar.gz使用方法比较简单tar -zxvf percona-xtrabackup-2.4.28-linux-x86_64.glibc2.12.tar.gz -C /usr/local ln -s /usr/local/percona-xtrabackup-2.4.28/bin/xtrabackup /usr/local/bin/xtrabackup ln -s /usr/local/percona-xtrabackup-2.4.28/bin/innobackupex /usr/local/bin/innobackupex解压后bin目录里同时包含xtrabackup和innobackupex。用软链把两个可执行文件放入/usr/local/bin之后在任何目录下都可以直接调用。不过要特别说明“免安装”不等于“免依赖”。tar 包里确实把 Perl 脚本和部分二进制组件打到了一起但底层依赖的系统库仍然存在。如果在解压运行后遇到缺少.so文件的报错还是要回到 ldd 检查这一步。4. 装完别急着备份版本、动态库、时间同步三件套自检4.1 xtrabackup 与 innobackupex 的版本输出判断装完以后我习惯先执行版本命令而不是直接拿生产环境测试备份。xtrabackup --version正常输出大概长这样xtrabackup: recognized server arguments: ... xtrabackup version 2.4.28 based on MySQL server 5.7.41 Linux (x86_64) (revision id: ...)再执行innobackupex --version如果innobackupex因为缺少 Perl 模块而报Cant locate DBD/mysql.pm说明perl-DBD-MySQL还没有装上。补装后再执行能输出版本号才算真正安装完整。版本输出的意义不只是确认“装了没”更重要的是确认你手里的二进制确实对应 MySQL 5.7 系列。如果输出的版本前缀不是2.4那后面一切备份动作都没有意义。4.2 用 ldd 快速锁定缺失动态库离线环境里最实用的诊断命令就是lddldd /usr/local/bin/xtrabackup或者ldd $(which xtrabackup)如果输出中有libev.so.4 not found libaio.so.1 not found那就说明对应依赖没有安装。解决办法是在离线机器的系统软件源中补装这些库安装完成后再次ldd直到所有依赖都指向lib64或/usr/lib路径。如果库文件明明存在但ldd仍然显示 not found可以执行ldconfig -p | grep libev查看缓存再用ldconfig刷新动态库缓存。不要一上来就设置全局LD_LIBRARY_PATH那会掩盖潜在的版本问题。4.3 离线服务器的时间漂移会连累备份验证离线服务器往往没有正常的 NTP 网络时间漂移很常见。XtraBackup 的备份和恢复主要依赖 LSN对时间敏感度没有想象的那么高但如果你的备份任务是用crontab 时间戳目录来组织的时间漂移会导致备份文件被错误覆盖或者备份顺序混乱。进入离线环境后先看一下时间状态timedatectl chronyc tracking如果发现系统时间和真实时间差很多建议在离线网络上配置一台内网 NTP 服务器或者至少用date -s手动校准到同一时间基准。后续检查备份文件时时间戳一致性能省掉很多不必要的猜测。5. 离线环境第一次备份容易倒在权限上而不是安装上5.1 备份用户的最小权限建议很多朋友装完 XtraBackup 后直接用 MySQL root 账号去测试备份。为了安全我建议单独创建一个备份账号CREATE USER backuplocalhost IDENTIFIED BY BackupStrongPass; GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO backuplocalhost; GRANT SELECT ON performance_schema.* TO backuplocalhost; FLUSH PRIVILEGES;这些权限对应什么作用RELOAD用于执行FLUSH TABLES WITH READ LOCK保证备份开始时数据一致性LOCK TABLES用于 InnoDB 之外的表加锁PROCESS用于查看当前线程和状态REPLICATION CLIENT用于获取 binlog 坐标和备份位点。5.2 target-dir、datadir 和运行身份的关系XtraBackup 的--target-dir不能是已经存在且非空目录否则会直接报错。第一次测试时可以先建一个空目录mkdir -p /data/backup/base chown mysql:mysql /data/backup然后用 mysql 用户运行备份命令避免生成一堆 root 属主的备份文件su -s /bin/sh mysql -c xtrabackup --backup --userbackup --passwordBackupStrongPass --target-dir/data/backup/base备份完成后检查目录ls -lh /data/backup/base如果看到大量 root 属主的文件后面做恢复时还需要chown -R mysql:mysql但不如一开始就规划好运行身份。5.3 磁盘空间与备份文件组织离线环境通常没有弹性扩容能力所以我习惯在备份前先确认磁盘du -sh /var/lib/mysql df -h /data/backup完整备份的大小会和datadir实际占用直接相关还需要额外预留一点空间存放备份过程中的临时文件和日志。如果磁盘空间接近满立刻停止备份不要赌“应该够用”。6. 跑通离线安装后我建议保留的三个长期习惯6.1 建立本地软件仓避免每次离线都重新找包第一次离线安装成功后把/tmp/pxb24目录保留下来放到内网服务器上作为一个本地软件源。RPM 系列可以用createrepo /data/repo/rpm之后其他内网服务器安装时直接配置一个local.repo指向该目录即可。这样以后再次安装 XtraBackup就不需要每次都在联网机器上重新下载。6.2 记录版本、校验和与安装现场离线环境没有外网重新下载代价高所以我习惯在安装完成后生成一个清单sha256sum /tmp/pxb24/*.rpm /opt/pxb24_sha256.txt uname -a cat /etc/os-release这个清单既是后续维护的重要依据也能在团队交接时让接手的人一眼看出当时装了哪些包、是什么版本。比所谓“经验”更可靠。6.3 把安装验证写成脚本留给后续接手的人安装完成后写一个简短的验证脚本#!/bin/bash set -e xtrabackup --version innobackupex --version if ldd $(which xtrabackup) | grep not found; then echo Missing shared libraries exit 1 fi echo XtraBackup offline install check passed以后不管是例行巡检还是迁移到新机器都可以直接用这个脚本判断安装是否完整。我现在做离线安装时通常就是“版本确认、依赖下载、传包安装、ldd 自检”四步走完最后留一份校验和清单。最深的体会有两个一是别跳过下载阶段直接拷包二是安装失败时保留日志比重新复制新包更有用。离线环境下的问题大多不是软件本身的问题而是包和依赖之间差了那么一层找到那一层XtraBackup 就能安安静静地把备份做好。 
长河君 · 2026/10/17 12:39:13 · 阅读 1.2k 离线安装Percona XtraBackup 2.4：依赖下载、安装与验证全指南
离线安装 percona-xtrabackup-24 这个需求通常出现在内网数据库集群、隔离机房或者没有外网权限的服务器上。明明在可联网的机器上几分钟就能装好的备份工具一旦换成离线环境很多人就卡在“包拷进去了命令却跑不起来”这一步。我前阵子做 MySQL 5.7 数据迁移时就因为在下载依赖时少拉了一个libev.so.4在离线服务器上折腾了大半天最后用ldd才定位到问题。这篇文章把完整流程写出来版本怎么选、依赖怎么下载、RPM / deb / tar 包怎么装、装完怎么验证以及第一次备份前容易踩的权限坑适合运维、DBA 和刚接触 XtraBackup 的开发者直接参考。1. 离线安装前先定版本2.4 系列和你的 MySQL 版本必须匹配1.1 2.4 为什么是 MySQL 5.6 / 5.7 环境里的安全牌Percona XtraBackup 2.4 并不是“比 8.0 更旧”的版本而是面向 MySQL 5.6、5.7 的对应版本。它和 MySQL 8.0 使用的 Percona XtraBackup 8.x 是两套独立工具链核心区别在于 redo log 格式、数据页校验和机制以及对新版本 MySQL 特性的支持。如果在 MySQL 5.7 实例上误用了 XtraBackup 8.0 的二进制备份阶段可能还能跑一段但 prepare 或恢复阶段大概率会碰到 redo log 不兼容的报错。这个错误在离线环境里非常致命因为你想临时换一个正确版本的包还得重新走一遍下载、传输、依赖验证的流程。因此我建议离线环境的目标机器如果是下面这种版本组合数据库版本推荐 XtraBackup 版本说明MySQL 5.6 / 5.7XtraBackup 2.4 系列工具链匹配度最高MySQL 8.0 / 8.4XtraBackup 8.x 系列直接使用 8.0 对应版本MariaDB 大部分版本需单独评估部分场景下需要看特定兼容性提示离线部署时不要单纯追求“下载最新 XtraBackup”要先把目标 MySQL 版本号确认清楚再确定下载 2.4 或 8.x。1.2 二进制包与发行版、glibc 的匹配关系同一个 XtraBackup 2.4针对不同 Linux 发行版有不同的包名。比如 CentOS 7 上常见的percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm其中的el7就是发行版标识Ubuntu 18.04 / 20.04 上则是bionic、focal后缀的.deb包此外还有面向通用 Linux 的glibc2.12tar 包。这些二进制不是简单的“x86_64 就能通用”。编译时链接的 glibc、OpenSSL、libcurl 等动态库版本不同跨发行版使用很容易出现找不到共享库的报错。离线环境最常见的翻车场景就是有人把 CentOS 8 的 el8 rpm 包拷到 CentOS 7 机器上rpm -ivh时提示依赖冲突或者干脆直接解压 tar 包一跑xtrabackup --version系统提示缺少某个GLIBC_2.28符号。注意在下载阶段就要把包名完整保留并把“目标操作系统版本、架构、XtraBackup 小版本号”一起记下来。这是离线安装最容易被忽略但最值得先做的一步。2. 在可联网机器上把依赖链一次性拉全离线最难的是这一步2.1 yumdownloader 与 downloadonlyRPM 系的一键拉包对 CentOS / RHEL 系统我会先准备一台和离线目标相同大版本、同样架构的机器然后使用yumdownloader把软件包和依赖全部拉下来yum install -y yum-utils mkdir -p /tmp/pxb24 yumdownloader --resolve --destdir/tmp/pxb24 percona-xtrabackup-24这里的--resolve参数非常关键。它会自动解析并下载一切需要的依赖不只是主程序本身。最终/tmp/pxb24目录里会留下一堆rpm包比如percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm、libev-4.15-7.el7.x86_64.rpm、libaio-0.3.109-13.el7.x86_64.rpm、numactl-libs-2.0.12-5.el7.x86_64.rpm等等。如果系统里没有yumdownloader还可以用另一种方式yum install --downloadonly --downloaddir/tmp/pxb24 percona-xtrabackup-24两种方式效果类似我个人更常用yumdownloader --resolve因为输出更清晰也不会真的把包安装到本机避免污染这台下载机器自身的环境。注意在联网机器上执行前要先配置好 Percona 官方软件源或者把之前已经下载好的 Percona rpm 包放到一个本地目录中作为安装源。2.2 apt-get download 与依赖解析deb 系容易漏包Debian / Ubuntu 上的离线下载稍微麻烦一点。apt-get download只会下载指定的软件包不会自动拉依赖。所以你需要先看依赖关系再逐个下载apt-get update apt-get download percona-xtrabackup-24 apt-cache depends percona-xtrabackup-24更省事的做法是使用apt-get install --download-only --no-install-recommends percona-xtrabackup-24这个命令会把主包以及依赖.deb都缓存在/var/cache/apt/archives目录里之后直接把目录中的所有.deb文件一起拷到离线机器即可。需要注意不要把在线机器上所有缓存的.deb一股脑复制进目标机器再用dpkg -i暴力安装。有些包目标机器可能已经有更新版本强行覆盖反而会把系统环境搞乱。按需选择依赖更稳妥。2.3 常见缺库报错和对应依赖清单离线安装中卡住大家的其实大多是动态库问题。我把几个常见报错列出来方便安装失败时快速对照典型报错信息大概率缺的依赖RPM 系列包名参考error while loading shared libraries: libev.so.4libevlibeverror while loading shared libraries: libaio.so.1libaiolibaioCant locate DBD/mysql.pmPerl MySQL 驱动perl-DBD-MySQLCant locate DBI.pmPerl DBI 模块perl-DBIerror while loading shared libraries: libnuma.so.1NUMA 库numactl-libserror while loading shared libraries: libcurl.so.4curl 运行库libcurl这些依赖在离线机器的系统安装光盘、系统镜像或内网软件源里一般都能找到。优先用系统自带的软件仓库补装而不是去第三方网站下载否则又会引入新的版本兼容问题。3. 三种离线安装法RPM、deb、免安装 tarball 的实操差异3.1 RPM 系使用 yum localinstall 而不是 rpm -ivh把/tmp/pxb24下的 rpm 包传到离线服务器后我一般首选yum localinstall -y /tmp/pxb24/*.rpm如果目标机器是 CentOS 8 或更新的发行版命令可以写成dnf localinstall -y /tmp/pxb24/*.rpmyum localinstall的本质是把本地目录当作一个临时软件源可以在当前目录中解析依赖关系。只要/tmp/pxb24里的包是完整的就能一次性装完。rpm -ivh是备用方案不过它不会自动解析依赖一旦缺少某个依赖就只输出一句“Failed dependencies”然后你看半天也不知道该去哪个仓库找。更不要用rpm -ivh --nodeps强行绕过依赖结果往往是rpm -qa能查到包但一执行xtrabackup --version系统直接报缺库。这种情况在离线环境里很难补救因为报错信息会指向某个具体的.so文件你还得回到联网机器去搜索对应版本。3.2 deb 系使用 dpkg -i 时的补依赖顺序deb 系离线安装常规做法是把下载好的.deb文件放到目标目录然后dpkg -i /tmp/pxb24/percona-xtrabackup-24*.deb如果报出dependency problems先别慌。看一下具体提示缺什么再从联网机器上下载对应的.deb传输进来后再执行一次dpkg -i /tmp/pxb24/*.deb必要的时候配合apt-get install -f但这个命令在离线环境里通常会因为没有外网而失败所以最可靠的方法还是把依赖.deb都补齐后再安装。不建议用dpkg --force-depends -i强行忽略依赖。这样虽然包能装上但下次运行xtrabackup时很可能因为缺少动态库而报错到时候排查起来比一开始就补全依赖要麻烦得多。3.3 tar.gz 解压方式软链和 PATH 配置除了 rpm 和 debXtraBackup 2.4 官方还提供免安装的 tar.gz 包比如percona-xtrabackup-2.4.28-linux-x86_64.glibc2.12.tar.gz使用方法比较简单tar -zxvf percona-xtrabackup-2.4.28-linux-x86_64.glibc2.12.tar.gz -C /usr/local ln -s /usr/local/percona-xtrabackup-2.4.28/bin/xtrabackup /usr/local/bin/xtrabackup ln -s /usr/local/percona-xtrabackup-2.4.28/bin/innobackupex /usr/local/bin/innobackupex解压后bin目录里同时包含xtrabackup和innobackupex。用软链把两个可执行文件放入/usr/local/bin之后在任何目录下都可以直接调用。不过要特别说明“免安装”不等于“免依赖”。tar 包里确实把 Perl 脚本和部分二进制组件打到了一起但底层依赖的系统库仍然存在。如果在解压运行后遇到缺少.so文件的报错还是要回到 ldd 检查这一步。4. 装完别急着备份版本、动态库、时间同步三件套自检4.1 xtrabackup 与 innobackupex 的版本输出判断装完以后我习惯先执行版本命令而不是直接拿生产环境测试备份。xtrabackup --version正常输出大概长这样xtrabackup: recognized server arguments: ... xtrabackup version 2.4.28 based on MySQL server 5.7.41 Linux (x86_64) (revision id: ...)再执行innobackupex --version如果innobackupex因为缺少 Perl 模块而报Cant locate DBD/mysql.pm说明perl-DBD-MySQL还没有装上。补装后再执行能输出版本号才算真正安装完整。版本输出的意义不只是确认“装了没”更重要的是确认你手里的二进制确实对应 MySQL 5.7 系列。如果输出的版本前缀不是2.4那后面一切备份动作都没有意义。4.2 用 ldd 快速锁定缺失动态库离线环境里最实用的诊断命令就是lddldd /usr/local/bin/xtrabackup或者ldd $(which xtrabackup)如果输出中有libev.so.4 not found libaio.so.1 not found那就说明对应依赖没有安装。解决办法是在离线机器的系统软件源中补装这些库安装完成后再次ldd直到所有依赖都指向lib64或/usr/lib路径。如果库文件明明存在但ldd仍然显示 not found可以执行ldconfig -p | grep libev查看缓存再用ldconfig刷新动态库缓存。不要一上来就设置全局LD_LIBRARY_PATH那会掩盖潜在的版本问题。4.3 离线服务器的时间漂移会连累备份验证离线服务器往往没有正常的 NTP 网络时间漂移很常见。XtraBackup 的备份和恢复主要依赖 LSN对时间敏感度没有想象的那么高但如果你的备份任务是用crontab 时间戳目录来组织的时间漂移会导致备份文件被错误覆盖或者备份顺序混乱。进入离线环境后先看一下时间状态timedatectl chronyc tracking如果发现系统时间和真实时间差很多建议在离线网络上配置一台内网 NTP 服务器或者至少用date -s手动校准到同一时间基准。后续检查备份文件时时间戳一致性能省掉很多不必要的猜测。5. 离线环境第一次备份容易倒在权限上而不是安装上5.1 备份用户的最小权限建议很多朋友装完 XtraBackup 后直接用 MySQL root 账号去测试备份。为了安全我建议单独创建一个备份账号CREATE USER backuplocalhost IDENTIFIED BY BackupStrongPass; GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO backuplocalhost; GRANT SELECT ON performance_schema.* TO backuplocalhost; FLUSH PRIVILEGES;这些权限对应什么作用RELOAD用于执行FLUSH TABLES WITH READ LOCK保证备份开始时数据一致性LOCK TABLES用于 InnoDB 之外的表加锁PROCESS用于查看当前线程和状态REPLICATION CLIENT用于获取 binlog 坐标和备份位点。5.2 target-dir、datadir 和运行身份的关系XtraBackup 的--target-dir不能是已经存在且非空目录否则会直接报错。第一次测试时可以先建一个空目录mkdir -p /data/backup/base chown mysql:mysql /data/backup然后用 mysql 用户运行备份命令避免生成一堆 root 属主的备份文件su -s /bin/sh mysql -c xtrabackup --backup --userbackup --passwordBackupStrongPass --target-dir/data/backup/base备份完成后检查目录ls -lh /data/backup/base如果看到大量 root 属主的文件后面做恢复时还需要chown -R mysql:mysql但不如一开始就规划好运行身份。5.3 磁盘空间与备份文件组织离线环境通常没有弹性扩容能力所以我习惯在备份前先确认磁盘du -sh /var/lib/mysql df -h /data/backup完整备份的大小会和datadir实际占用直接相关还需要额外预留一点空间存放备份过程中的临时文件和日志。如果磁盘空间接近满立刻停止备份不要赌“应该够用”。6. 跑通离线安装后我建议保留的三个长期习惯6.1 建立本地软件仓避免每次离线都重新找包第一次离线安装成功后把/tmp/pxb24目录保留下来放到内网服务器上作为一个本地软件源。RPM 系列可以用createrepo /data/repo/rpm之后其他内网服务器安装时直接配置一个local.repo指向该目录即可。这样以后再次安装 XtraBackup就不需要每次都在联网机器上重新下载。6.2 记录版本、校验和与安装现场离线环境没有外网重新下载代价高所以我习惯在安装完成后生成一个清单sha256sum /tmp/pxb24/*.rpm /opt/pxb24_sha256.txt uname -a cat /etc/os-release这个清单既是后续维护的重要依据也能在团队交接时让接手的人一眼看出当时装了哪些包、是什么版本。比所谓“经验”更可靠。6.3 把安装验证写成脚本留给后续接手的人安装完成后写一个简短的验证脚本#!/bin/bash set -e xtrabackup --version innobackupex --version if ldd $(which xtrabackup) | grep not found; then echo Missing shared libraries exit 1 fi echo XtraBackup offline install check passed以后不管是例行巡检还是迁移到新机器都可以直接用这个脚本判断安装是否完整。我现在做离线安装时通常就是“版本确认、依赖下载、传包安装、ldd 自检”四步走完最后留一份校验和清单。最深的体会有两个一是别跳过下载阶段直接拷包二是安装失败时保留日志比重新复制新包更有用。离线环境下的问题大多不是软件本身的问题而是包和依赖之间差了那么一层找到那一层XtraBackup 就能安安静静地把备份做好。