备份完成后必须立即计算md5校验码，使用md5sum生成校验文件并与备份同目录存放，恢复前用md5sum -c验证，物理备份需逐文件校验，自动化脚本中须集成且控制io影响。
备份完成后立刻计算MD5，别等恢复时才发现文件损坏
MySQL本身不校验备份文件完整性，mysqldump 或 mysqlpump 输出的SQL文件、xtrabackup 生成的二进制备份包，都可能因磁盘写入失败、网络中断或存储挂载异常而截断或静默损坏。必须在备份命令执行完毕后、文件离开源服务器前，立即算一次MD5。
- 用
md5sum backup.sql > backup.sql.md5生成校验文件，和备份文件放同一目录，避免路径错位 - 若备份走管道（如
mysqldump ... | gzip > backup.sql.gz），MD5必须对压缩后文件算：md5sum backup.sql.gz，不是原始SQL流 - 不要依赖远程存储（如S3、NAS）自带的ETag——S3的ETag对多段上传不等于MD5，NAS的校验常被缓存绕过
验证时比对的是本地MD5文件，不是重新计算
恢复前校验不是再跑一遍 md5sum，而是用 md5sum -c backup.sql.md5 命令让系统自动读取校验文件里的哈希值并比对。这个动作能发现文件名变更、权限丢失导致的读取失败，比手动 diff 更可靠。
-
backup.sql.md5文件本身也要一起校验——它若被篡改或写坏，整个验证就失效；建议用sha256sum单独保护该文件 - 若校验报错
backup.sql: FAILED，先检查文件权限是否为只读导致md5sum -c无法读取，而不是直接重做备份 - 跨平台传输（如Windows传到Linux）要注意换行符：如果备份是SQL且含
\r\n，在Linux下重新计算MD5会不一致——此时应统一用dos2unix处理后再校验
物理备份（XtraBackup）的MD5必须分卷计算
xtrabackup 的全量备份通常是一堆文件（xtrabackup_checkpoints、ibdata1、多个 .ibd），不能只对顶层目录打包再算一个MD5。任意一个数据文件损坏，整个恢复都会失败。
- 用
find /path/to/backup -type f -exec md5sum {} \; > backup.md5逐文件生成校验，再用md5sum -c backup.md5验证 - 跳过临时文件：
find ... -not -name "*tmp*" -not -name "xtrabackup_logfile"，否则日志文件大小波动会导致误报 - 注意
innodb_page_size不同的实例，.ibd文件结构不同，MD5天然不一致——验证前确认源备环境配置一致
自动化脚本里别省掉校验步骤，但要控制IO影响
把 md5sum 写进备份脚本是必须的，但大库（>100GB）上直接 md5sum 会拉高磁盘IO，可能拖慢备份或影响线上业务。
- 加
ionice -c2 -n7降低IO优先级：ionice -c2 -n7 md5sum backup.sql > backup.sql.md5 - 避免校验压缩包内文件：如果用
gzip压缩，zcat backup.sql.gz | md5sum是解压+计算，CPU和IO双开销；不如直接校验backup.sql.gz文件本身 - 校验结果必须写入日志并触发告警——仅打印到终端没用，脚本退出码为0不代表成功，要检查
md5sum -c的返回值是否为0
gpg --sign 或 sha256sum 替代，但前提是验证流程得先跑通——多数故障出在校验没执行，而不是哈希算法选得不够强。
