不能直接比对归档前后md5确保绝对一致性，因tar引入元数据和顺序不确定性；应分层校验：先备份前逐文件生成内容哈希，再验证tar包完整性，接着解压后比对恢复文件哈希，最后对数据库等做逻辑校验。
直接比对归档前后的 MD5 值，不能确保“绝对一致性”，因为 tar 归档本身会引入元数据（如路径、权限、时间戳、稀疏块处理等）和打包顺序的不确定性。MD5 只校验文件内容，而 tar 包不是纯内容容器——它封装了结构信息。所以正确做法是：**不比对 tar 包与原始文件的 MD5，而是分层校验：先保内容一致，再保归档可用，最后保恢复可靠。**
第一步：备份前对源文件逐个生成内容哈希
用脚本遍历源目录，为每个文件计算并记录其内容 MD5（或更推荐 sha256sum），忽略路径、权限等元数据：
- 命令示例：
find /data -type f -print0 | xargs -0 sha256sum > /backup/20260721_source.sha256 - 关键点：只针对 regular file；避免符号链接、设备文件干扰结果
- 生成的校验文件必须保存在独立位置（如另一块盘或远程存储），防止同盘故障导致双损
第二步：归档后立即验证 tar 包自身完整性
tar 包生成后，立刻用 tar -tzf 检查能否正常列出内容，这能捕获压缩损坏、截断、写入失败等基础问题：
- 执行：
tar -tzf backup_20260721.tar.gz > /dev/null || { echo "tar broken"; exit 1; } - 补充校验：
sha256sum backup_20260721.tar.gz > backup_20260721.tar.gz.sha256，用于后续传输/存储验证 - 注意：不要用
md5sum校验 tar 包本身——它防不了恶意篡改，生产环境请统一用 sha256sum
第三步：解压后比对恢复文件与原始哈希
把 tar 包解压到临时目录，再用之前生成的 source.sha256 文件校验还原出的每个文件：
- 命令：
cd /restore_tmp && sha256sum -c /backup/20260721_source.sha256 --quiet -
--quiet只输出失败项；成功时无输出，便于脚本判断 - 若某文件报
FAILED，说明该文件在备份或恢复过程中内容已变（如磁盘坏道、内存错误、IO 中断） - 注意：解压路径需与原始路径结构一致，或提前用
--transform统一前缀，否则校验路径不匹配
第四步：数据库等结构化数据要额外做逻辑校验
文件级哈希通过，不代表业务数据就正确。例如 MySQL 表可能成功恢复，但因字符集转换丢失末尾空格，或时间字段精度被截断：
- 执行
SELECT COUNT(*), MD5(GROUP_CONCAT(... ORDER BY id)) FROM table_name;对关键表抽样生成行级摘要 - 对比源库与恢复库的结果值，比单纯看行数更可靠
- 对大表启用分块校验：按主键 ID 分段（如
WHERE id BETWEEN 1 AND 10000），降低单次查询压力 - 配合
mysqldump --skip-extended-insert导出后用diff直接比对 SQL 内容（适合中小规模）
