先区分SQL逻辑备份或xtrabackup物理备份损坏类型，再分别用head/tail检查文件完整性或apply-log验证目录结构；SQL部分损坏可截取有效段并加--force导入，binlog仅适用于逻辑恢复。
备份文件被截断或校验失败，先确认损坏类型
MySQL 备份损坏不是单一问题，得先分清是 mysqldump 生成的 SQL 文件损坏，还是 xtrabackup 的物理备份目录结构异常。常见现象包括：ERROR 1064（SQL 语法错误）、mysql 导入时卡在某行、innobackupex: error: cannot open file 'xtrabackup_info'、或解压后发现 ibdata1 文件大小为 0。
关键动作：用 head -n 20 backup.sql 看开头是否含 CREATE DATABASE 和注释头；用 tail -n 20 backup.sql 看结尾是否含 -- Dump completed；对 xbbackup，运行 innobackupex --apply-log --redo-only /path/to/backup 观察是否报错。
SQL 备份文件部分损坏，尝试跳过坏段重导
如果 mysql 导入时报错在某一行（如 ERROR 1064 at line 128456），说明前面内容基本可用。不要直接放弃整个备份。
- 用
sed -n '1,128455p' backup.sql > backup_fixed.sql截取前若干行，再手动补上缺失的COMMIT;或表结构末尾分号 - 加
--force参数让mysql忽略单条语句错误：mysql -u root -p --force ，但需事后检查日志中跳过的语句数 - 若损坏集中在某个大表，可先用
sed -n '/^-- Table structure for table `t_user`/,/^-- Table structure for table `/p' backup.sql提取该表，单独修复
Percona XtraBackup 物理备份损坏，优先检查 xtrabackup_checkpoints
物理备份依赖一致性检查点文件，一旦 xtrabackup_checkpoints 缺失或 to_lsn 字段为 0，--apply-log 就会失败，无法启动实例。
实操建议：
- 确认备份目录下是否存在
xtrabackup_checkpoints，内容应类似：backup_type = full-prepared、to_lsn = 123456789 - 若文件存在但
to_lsn异常低，可能是备份中途被 kill，此时不能强行--apply-log，否则数据字典与 ibd 不一致 - 若有多个连续备份（全量 + 增量），可尝试用上一个成功的
to_lsn值覆盖当前文件中的to_lsn，再重跑--apply-log（仅限测试环境验证）
没有可用备份时，从 binlog 拼凑最近变更
当所有备份都不可用，且开启了 binlog（log_bin = ON），这是最后一道防线。但前提是知道损坏发生的大致时间点，且 binlog 未被 purge。
操作路径：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A 5 -B 5 'DELETE FROM orders'定位误操作位置 - 提取指定时间段的 binlog：
mysqlbinlog --start-datetime="2024-04-01 10:00:00" --stop-datetime="2024-04-01 10:30:00" mysql-bin.000012 > recover.sql - 注意：ROW 格式下需用
--base64-output=DECODE-ROWS -v才能读出真实字段值；STATEMENT 格式则直接可读，但可能因函数/临时表导致重放失败
binlog 恢复本质是“重放”，不解决已丢失的物理页损坏，只适用于逻辑误删、误更新等场景。真正坏块级损坏，没备份就只能接受数据丢失。
