必须验证恢复路径是否通畅，否则仅执行mongodump或触发atlas备份不等于拥有可用备份；副本集恢复依赖oplog完整性、fcv兼容性及restoreinfo.txt中启动参数匹配；跨版本恢复时fcv锁死主版本号，加密备份还需确保密钥可加载。
备份后必须验证恢复路径是否通，否则等于没备
只执行 mongodump 或触发 Atlas 备份不等于拥有可用备份。副本集的备份可恢复性取决于三个硬条件：oplog 完整性、FCV 兼容性、以及 restoreInfo.txt 中记录的启动参数能否被目标实例满足。跳过验证，恢复时大概率卡在 mongod 启动失败或数据不一致。
用 mongorestore + --dryRun 快速检查备份结构
该参数从 MongoDB 6.0 开始支持，不写入数据，仅校验备份文件格式、集合元信息和 BSON 兼容性：
mongorestore --dryRun --uri "mongodb://localhost:27017" /backup/mongo_20260720/- 若报错
invalid BSON element type，说明备份中含 BinData 子类型 2 数据，而目标版本默认用子类型 0 —— 需确认应用是否适配 - 若提示
collection metadata missing，可能是mongodump执行时未加--oplog，导致无时间点上下文，无法用于一致性恢复
真正验证必须拉起临时副本集跑一次完整恢复
生产环境的最小验证闭环是：解压备份 → 启动单节点临时实例 → 初始化为副本集 → 检查 oplog 回放状态。关键动作如下：
- 用
restoreInfo.txt中的storage engine和mongod startup options启动临时实例，例如：mongod --dbpath /tmp/restore --replSet rs0 --port 27018 --bindIp 127.0.0.1 - 连接后执行
rs.initiate()，再运行rs.printSecondaryReplicationInfo()确认 oplog 起始时间早于备份时间戳 - 检查
local.oplog.rs是否有连续写入，避免因备份期间写入被丢弃导致后续故障转移失败 - 不要跳过这步：用业务查询语句（如
db.orders.findOne({status: "pending"})）比对原始数据与恢复后结果
跨版本恢复时 FCV 是隐形雷区
备份创建时的 FCV（Feature Compatibility Version）会锁死恢复目标的主版本号。比如备份来自 mongodb 8.1.5 且 FCV=8.1，则：
- 可恢复到
8.2.x或9.0.x，但不能到8.0.x（次要版本更低） - 若目标集群 FCV 已升至 9.0，而备份 FCV 是 8.1，
mongod启动时会直接拒绝加载数据目录，并报错incompatible FCV - 验证前先查源集群 FCV：
db.adminCommand({getFeatureCompatibilityVersion: 1})，再比对目标集群输出
真正麻烦的是加密备份：restoreInfo.txt 里写的 main key UUID 必须能在目标环境通过 KMIP 或本地证书加载，否则连 mongod 进程都起不来——这点常被忽略，直到恢复失败才排查。
