备份与恢复是方向相反但强耦合的操作：备份存数据，恢复放回数据；逻辑备份（mysqldump）跨版本兼容但导入慢，物理备份（xtrabackup）秒级恢复但要求环境严格一致；增量依赖binlog或xtrabackup差异页，恢复失败多因权限、路径及时序错误。
备份和恢复本质是两个方向相反但强耦合的操作
备份是把当前数据“存下来”，恢复是把存下来的数据“放回去”——听起来简单，但实际中，一次失败的恢复会让备份完全失效。很多团队花大力气做每日全量备份，却从不验证能否真正还原，直到某天 drop database 执行后才意识到：备份文件能 ls 出来，不代表能 mysql 导入成功。
逻辑备份（mysqldump）与物理备份（xtrabackup）的根本差异
区别不在“快不快”，而在“能不能跨版本、跨平台、保事务一致性”：
-
mysqldump输出的是 SQL 文本，可被vim编辑、grep过滤、在 MySQL 5.7 和 8.0 甚至 MariaDB 上执行（需注意语法兼容性），但导入时要重放所有INSERT，大表可能卡住数小时； -
xtrabackup复制的是 InnoDB 的页文件，恢复就是把文件拷回datadir并启动服务，秒级完成，但必须保证源库和目标库的 MySQL 版本、架构（x86/ARM）、InnoDB page size 完全一致，否则直接启动失败； - 一致性保障方式不同：
mysqldump --single-transaction依赖 MVCC 快照，而xtrabackup依赖ib_logfile回滚未提交事务，两者都要求引擎为 InnoDB；MyISAM 表在热备下极易不一致，应避免使用。
增量备份不是“只备份变化”，而是依赖 binlog 或 xtrabackup 的 checkpoint
MySQL 原生不支持传统意义上的增量物理备份。所谓“增量”，其实是两种路径：
- 用
xtrabackup --incremental-basedir做基于上一次全量或增量备份的差异页拷贝，恢复时必须按顺序--apply-log全量 + 所有增量，漏一个就无法前滚； - 靠
binlog实现准实时增量：全量备份后开启log_bin，定期滚动并归档mysql-bin.0000xx文件；恢复时先还原全量，再用mysqlbinlog --stop-datetime回放到故障前一秒——但前提是binlog_format=ROW且没被 purged。 - 常见坑：
mysqldump默认不导出binlog位置，若没加--master-data=2，就无法精准定位起点；而xtrabackup备份完成时生成的xtrabackup_binlog_info文件若被误删，增量链就断了。
恢复失败最常卡在权限、路径和时序这三点
别急着 mysql -u root -p —— 先确认三件事：
- 目标实例的
sql_mode是否和备份时一致？比如备份含STRICT_TRANS_TABLES，而恢复库关了严格模式，可能跳过报错但写入脏数据； -
backup.sql里是否有CREATE DATABASE语句？用了mysqldump -B就有，直接mysql导入即可；若没加-B，得先手动CREATE DATABASE再导入，否则报错Unknown database； - 物理恢复后，必须确保
chown -R mysql:mysql /var/lib/mysql，且innodb_data_home_dir和datadir配置指向正确路径，否则 MySQL 启动日志里只显示InnoDB: Database page corruption，不告诉你哪一页坏了。
真正难的从来不是备份，而是让恢复过程可预测、可验证、可重复。每次备份后，至少应在测试环境跑一次 innobackupex --apply-log && --copy-back 或 mysql ，并校验几条关键记录的 CHECKSUM TABLE 值是否一致。
