不能直接对mongos执行mongodump，因其仅转发查询、不感知分片拓扑，导致跨分片状态不一致、chunk迁移漏文档、config与shard数据不同步；必须停写、停均衡器，并分别备份config server和各shard primary的oplog对齐数据。
分片集群的备份不能靠单个 mongodump 命令搞定，必须协调所有组件（配置服务器、所有分片副本集）并控制写入与均衡器——否则备份出来的数据大概率不一致。
为什么不能直接对 mongos 执行 mongodump
对 mongos 运行 mongodump 只会导出路由元数据和部分查询结果，无法保证跨分片操作的原子性，更不会捕获各分片底层的数据状态。尤其当有正在进行的块迁移或未提交事务时，备份数据可能缺失、重复或处于中间态。
-
mongodump --host <mongos_url></mongos_url>实际走的是聚合查询路径，不是物理快照 - 不包含 oplog，无法做增量恢复，也无法保障一致性点
- 配置服务器（config server）的元数据（如
config.shards、config.chunks）必须单独、精确备份，否则恢复后集群无法识别分片拓扑
必须停写 + 停均衡器 + 分组件备份
自管理分片集群要获得强一致性备份，核心动作就三步：停写、停均衡器、按角色分别备份。任何跳过其中一项的操作，都属于“近似备份”，只适合开发环境回滚，不能用于生产灾难恢复。
- 执行
db.fsyncLock()或fsync命令前，先确认所有应用已停止写入；否则锁可能阻塞或失败 - 用
sh.stopBalancer()停止均衡器，并等待sh.getBalancerState()返回false且sh.isBalancerRunning()为false - 配置服务器备份：关闭一个 config server 实例（三个中任一），复制其
dbPath下全部文件；不要只 dumpconfig数据库——它不包含 WiredTiger 元数据和 journal - 每个分片备份：对每个分片副本集的 primary 节点 执行
mongodump --oplog --out /backup/shard01；注意--oplog是必须项，否则无法对齐时间点
文件系统快照是更稳妥的替代方案
如果停机窗口极短或业务完全不可中断，文件系统快照（LVM/ZFS/云盘快照）比 mongodump 更可靠，但前提是你能确保所有 mongod 进程处于静默状态（即已 fsyncLock 且无 pending 写入）。
- 快照前必须调用
db.fsyncLock()，完成后立即执行快照，再调用db.fsyncUnlock() - 加密存储引擎（ESE）用户需额外注意：冷快照恢复时必须加
--eseDatabaseKeyRollover参数启动，否则 AES256-GCM IV 重用会导致数据损坏 - Amazon EBS RAID 配置不支持原子快照，必须拆成单盘快照并严格按顺序恢复，否则 config server 与分片时间点错位
最容易被忽略的是配置服务器备份的完整性——只 dump config 库、或只 cp 其数据目录但漏掉 journal 和 wiredTiger 元数据文件，恢复后集群会卡在 “Waiting for majority vote” 状态，连 sh.status() 都无法返回。
