备份文件被截断或校验失败，先确认损坏类型
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 恢复本质是“重放”，不解决已丢失的物理页损坏，只适用于逻辑误删、误更新等场景。真正坏块级损坏，没备份就只能接受数据丢失。
