dbHash命令仅能比对运行中集群某时刻的状态快照，无法验证mongodump备份文件完整性；校验备份须遍历.bson文件，用mongorestore --dryRun --noIndexRestore检查文档解析与映射，分片集群还需单独验证config库元数据。
dbHash 命令只能比对同一时刻的校验和，不能验证备份文件本身
很多人误以为用 dbHash 导出的哈希值能直接用来验证 mongodump 备份包是否完整，其实不行。dbHash 是在运行中的 mongos 或 shard 上执行的实时计算，它不读取备份文件，也不解析 BSON 归档结构。你拿到的 {dbHash: "xxx"} 只是那一刻集群状态的快照指纹，和备份文件是否损坏、是否丢文档、是否漏集合完全无关。
真正要校验备份文件，得从归档内容入手：
-
mongodump生成的是 BSON + metadata.json 的目录结构，不是单个压缩包；校验必须遍历所有.bson文件 - 小集合可用
mongorestore --dryRun快速试载，看是否报invalid bson或字段截断 - 大备份建议用
bsondump --version检查工具版本兼容性（比如 5.0 dump 不能用 4.4 bsondump 解析） - 若备份含分片元数据（如
config.shards），需单独验证config库的mongodump输出，否则恢复后可能路由错乱
用 mongorestore --noIndexRestore + --dryRun 检查文档层完整性
这是最贴近生产实操的验证方式：跳过索引重建（避免因目标环境缺失依赖而失败），只校验文档能否被正确解析和映射。
执行命令示例：
mongorestore --dryRun --noIndexRestore --dir /path/to/backup/mydb/ mydb
关键点：
-
--dryRun不写入数据，但会完整走解析 → 解码 → BSON 验证流程 -
--noIndexRestore防止因目标库已有同名索引或权限不足中断校验 - 输出中一旦出现
Failed to parse bson、invalid utf8 string或field name cannot be empty，说明对应.bson文件已损坏 - 注意检查日志末尾是否有
done且无 error —— 很多人只扫开头，忽略最后几行的 summary 错误
备份时没停写入？用 oplog 追加校验才可靠
如果备份期间业务未停写，mongodump 默认不包含 oplog，备份点和实际一致性点存在偏差。此时仅校验备份文件本身意义有限。
补救办法是：在备份完成后立即从源集群拉一段 oplog，和备份时间戳对齐：
- 确认备份结束时间（如
2026-10-21T06:22:15Z） - 连上任意 shard 主节点，执行：
db.oplog.rs.find({ts: {$gte: Timestamp(1729491735, 1)}}).limit(1) - 导出该时间点之后的 oplog：
mongodump --db local --collection oplog.rs --query '{"ts": {"$gte": {"$timestamp": {"t": 1729491735, "i": 1}}}}' --out /tmp/oplog-after-backup - 恢复时先 restore 备份，再用
mongorestore导入这段 oplog（需目标环境开启oplog支持）
否则，所谓“完整性”只是静态快照完整，不是业务语义上的最终一致。
分片集群备份必须单独验证 config server 数据
多数人只 dump 各 shard 的业务库，却忘了 config 库才是分片集群的“大脑”。缺了它，mongorestore 后 sh.status() 直接报 config server not available 或 chunk 元数据丢失。
验证要点：
- 确保备份路径里有
config/子目录，且包含shards.bson、databases.bson、chunks.bson三个核心集合 - 用
mongorestore --dryRun config/单独跑一次 config 库校验（不加--drop） - 检查
chunks.bson文档数是否与线上sh.status()显示的 chunk 总数基本一致（允许少量迁移中差异） - 特别注意
tags和zones配置是否完整 —— 这些字段容易在 dump 时被忽略，但恢复后会导致数据分布异常
config 库出问题不会立刻报错，但会在后续 chunk 迁移或 balance 过程中突然卡死，排查成本极高。
