不能直接mongorestore恢复分片集群，因为该操作仅写入数据而未同步config库中的shards、databases、collections、chunks等路由元数据，导致mongos无法定位数据，查询返回空库或“collection not found”。
分片集群误删数据后，不能靠单个 mongorestore 直接还原——因为路由元数据（config 库）缺失，mongos 根本不知道数据该分到哪个分片，恢复后只会看到空库或部分数据。
为什么不能直接 mongorestore 到分片集群
分片集群的数据分布在多个分片上，但逻辑路由信息全存在 config 数据库里。误删操作（比如 db.collection.drop() 或 db.dropDatabase()）通常只影响业务库，但如果你连 config 也删了，或者备份里没包含它，mongorestore 即使把每个分片的 .bson 文件都还原进去，mongos 仍无法定位数据。
- 物理备份（LVM/文件系统快照）包含完整目录结构，含
config和各分片数据，是唯一能完整恢复分片集群的方式 - 逻辑备份（
mongodump）默认不导出config库，除非显式加--db config参数；且即使导出了，mongorestore也无法自动重建分片路由表（chunks、shards等集合） - 从 Atlas 或 Cloud Manager 恢复时，平台会自动同步
config和分片状态，但自建集群必须手动对齐
冷备份恢复必须加 --eseDatabaseKeyRollover（AES256-GCM 加密场景）
如果你的分片集群启用了加密存储引擎（storage.encryption 配置为 aes256-gcm），且是从 mongod 停机状态下做的冷备份（如 LVM 快照），直接启动会因 IV（初始化向量）重复导致数据损坏或读取失败。
- 错误现象：
mongod启动后日志出现invalid key counter或decryption failed，数据库无法打开 - 必须在首次启动时加参数：
./mongod --dbpath /data/shard1 --eseDatabaseKeyRollover，该命令会滚动密钥并退出，之后再正常启动 - 这个步骤只做一次，且仅对冷备份有效；热备份（mongod 运行中打的快照）不需要此操作
- 若跳过此步，后续所有写入都可能破坏加密一致性，ACID 保证失效
恢复前必须确认分片数量与角色配置一致
源集群和目标集群的分片数、配置服务器副本集（CSRS）成员数、以及各分片的 replica set 名称必须完全一致，否则 mongos 初始化失败或路由错乱。
- 检查原集群配置：连上任意分片主节点，运行
rs.conf()查_id和members；连上config服务器，查sh.status()确认分片列表 - 恢复后首次启动
mongos前，确保所有分片和 CSRS 已启动且健康；mongos会从config读取分片拓扑，如果某个分片地址不对或不可达，mongos就卡住不动 - MongoDB 8.0+ 引入
directShardOperations角色，可用于手动修复分片元数据，但风险极高——仅限支持团队指导下使用，日常恢复严禁启用
真正麻烦的不是拷文件或跑命令，而是 config 库里那几条 chunks 记录是否和你恢复进来的分片数据对得上。少一条、时间戳错一位，整个集合就查不到——这种问题不会报错，只会静默返回空结果。
