冷备份是数据库停机后直接复制数据文件的物理备份，热备份则通过xtrabackup等工具实现在线备份，二者需结合业务需求搭配使用；增量恢复依赖binlog精准定位事件。
MySQL 冷备和热备不是二选一的取舍，而是根据业务连续性要求、数据量大小和运维能力搭配使用的组合策略；增量恢复的关键不在“怎么备份”，而在于“如何精准定位并应用 binlog 事件”。
冷备份：停机换来的确定性
冷备份本质是数据库完全停止后，直接复制 /var/lib/mysql 目录下的所有文件（包括 ibdata1、ib_logfile*、.frm/.ibd 等）。它不依赖 MySQL 运行状态，也不需要额外配置，恢复时只需清空原目录、拷回文件、修正权限并重启服务。
- 适合非核心系统、夜间维护窗口、新环境初始化或数据迁移场景
- 必须确保 mysqld 已彻底停止（systemctl stop mysqld，而非 kill -9）
- 备份前建议执行 FLUSH TABLES WITH READ LOCK（虽已停机，但可避免未刷盘风险）
- 恢复时注意 SELinux 上下文与文件属主（chown -R mysql:mysql /var/lib/mysql）
热备份：XtraBackup 实现在线物理备份
Percona XtraBackup 是生产环境中最常用的热备份工具，支持 InnoDB 在线备份，对 MyISAM 表会自动加全局读锁。它能生成一致的物理快照，无需停机，且支持压缩、流式传输和增量备份链管理。
- 安装后使用 xtrabackup --backup --target-dir=/backup/inc20260707 --incremental-basedir=/backup/full20260701 可做增量
- 备份完成后必须执行 --prepare（合并日志、回滚未提交事务），否则无法恢复
- 恢复时先还原全量，再按顺序应用各次增量，最后用 --apply-log-only 处理中间增量
- 注意：XtraBackup 5.7 与 8.0 不兼容，版本需严格匹配 MySQL 版本
增量恢复：靠 binlog 实现时间点精确回退
逻辑增量依赖 MySQL 的二进制日志（binlog），它记录所有 DDL/DML 操作。恢复时，先还原最近一次全量（或全量+增量）备份，再从该备份对应的位置（position）或时间点（timestamp）开始重放 binlog。
- 确认已启用 log-bin 并设置 server-id（主从/恢复必需）
- 用 mysqlbinlog --base64-output=decode-rows -v mysql-bin.000003 查看事件详情
- 定位误操作前的 position：可通过 SHOW BINLOG EVENTS IN 'mysql-bin.000003' LIMIT 20,10 或解析日志中的 timestamp
- 恢复命令示例：mysqlbinlog --stop-datetime="2026-07-07 10:25:00" mysql-bin.000003 | mysql -u root -p
混合策略：全量 + 增量 + binlog 的三层保障
单一备份方式无法应对所有故障场景。推荐采用“每周一次 XtraBackup 全量 + 每日一次增量 + 持续归档 binlog”的三级结构，并配合定期恢复演练验证有效性。
- 全量备份保留 2–3 份，增量最多保留 7 天，binlog 至少保留 30 天（满足 PITR 需求）
- 每次备份后记录 mysql -e "SHOW MASTER STATUS" 输出，作为后续 binlog 恢复起点
- 关键业务建议开启 GTID，避免 position 错位导致跳过或重复执行
- 所有备份文件应异地存放（如对象存储或跨机房 NFS），并校验 md5/sha256
