直接用 mongodump 做全量备份不可行，因其默认无一致性保障；必须加 --oplog（副本集）或配合 fsyncLock 才能实现生产级一致快照，否则不同集合导出时间点错位，恢复后业务逻辑可能异常。
直接用 mongodump 做全量备份可行，但默认行为不保证一致性——尤其在副本集或有持续写入的场景下，容易导出“时间错位”的数据。必须加 --oplog 或配合 fsyncLock 才算真正可用的生产级全量备份。
为什么不能裸用 mongodump --out
默认执行 mongodump 时，它只是按顺序遍历每个集合发起查询，中间没有事务或快照机制。如果备份过程中有新文档插入、更新或删除，不同集合之间的时间点就不一致。比如 users 集合导出的是 10:00 的状态，orders 却是 10:02 的，恢复后业务逻辑可能出错。
- 单节点部署：风险较低，但仍有小概率出现游标失效或文档丢失
- 副本集部署：必须启用
--oplog，否则无法保证 oplog 时间线对齐 - 分片集群：
mongodump不适合直接用于生产分片集群全量备份，它无法协调各 shard 的一致时间点
正确执行全量备份的三个关键参数组合
以下命令适用于副本集（含单节点副本集），能生成带 oplog 截断点的一致性快照：
mongodump --host rs0/localhost:27017 --username admin --password pwd --authenticationDatabase admin --oplog --out /backup/mongo_$(date +%Y%m%d_%H%M%S)
-
--oplog：强制mongodump在备份开始前读取当前 oplog 起始位置，并在备份结束时记录结束位置，生成oplog.bson - 主机格式必须是
rs0/localhost:27017这类 replica set 名 + 成员地址，否则--oplog会被忽略（即使连的是副本集） - 输出目录不能是已有
dump/目录——mongodump会自动创建子目录结构，重复使用会导致覆盖或混杂
备份文件结构和后续验证要点
成功执行后，/backup/mongo_20260928_223000/ 下会有：
- 按库名分的子目录（如
myapp/），内含各集合的.bson和.json元数据 - 根目录下的
oplog.bson：这是增量恢复或时间点恢复的关键 - 没有压缩：若需节省空间，加
--gzip，但恢复时必须对应加--gzip，且不能和--archive混用
验证是否真的一致？别只看文件大小。进到备份目录运行：mongorestore --dryRun --noIndexRestore --numParallelCollections 1 /backup/mongo_20260928_223000，它会模拟导入流程并报告 oplog 范围，确认起止时间戳连续无 gap。
容易被忽略的权限与路径陷阱
实际跑失败，八成卡在这几个地方：
- 认证数据库写错：
--authenticationDatabase必须是用户实际创建所在的库，不是目标备份库（常见填成admin却误写为myapp） - oplog 权限缺失：用户需有
clusterAdmin或至少read权限在local库（因为 oplog 存在local.oplog.rs） - 输出路径磁盘满或无写权限：
mongodump不校验磁盘空间，直到写一半才报错，建议提前df -h /backup - 时间戳命名冲突：多个备份同秒级启动会覆盖，用
$(date +%Y%m%d_%H%M%S%3N)补毫秒更稳妥
oplog 文件本身不加密、不压缩，且只记录变更操作——它体积小但极其关键。删了它，就等于放弃了基于时间点恢复的能力。
