MongoDBNotes

第 22 章：备份恢复

zjc 于 2026-01-22 发布

这是《MongoDB 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 备份的价值只有通过恢复演练才能证明。MongoDB 备份必须同时考虑数据文件、副本集 oplog、分片 Config Server、事务一致性点和集群元数据。

22.1 目标

先定义：

目标 问题
RPO 最多丢多久数据
RTO 多久恢复服务
范围 哪些库、集合、元数据
场景 误删除、节点损坏、机房故障
恢复位置 原集群、临时集群、时间点

示例：

core collections RPO <= 5 minutes
restore rehearsal RTO <= 30 minutes
audit collections retain 365 days

22.2 备份对象

副本集：

  1. 数据文件；
  2. oplog；
  3. 用户和角色；
  4. 索引定义；
  5. 集合配置；
  6. mongod 配置；
  7. 密钥和证书配置说明。

分片集群额外需要：

  1. Config Server；
  2. shard 拓扑；
  3. chunk 元数据；
  4. zone 配置；
  5. mongos 配置；
  6. balancer 状态。

只备份业务集合而不备份元数据，恢复后路由可能不完整。

22.3 mongodump

逻辑备份：

mongodump \
  --uri="mongodb://backup_user:password@mongo1:27017,mongo2:27017,mongo3:27017/shop?replicaSet=rs0&authSource=admin" \
  --db=shop \
  --out=/backup/20260825 \
  --gzip

恢复：

mongorestore \
  --uri="mongodb://admin:password@restore-target:27017/admin" \
  --db=shop \
  --dir=/backup/20260825/shop \
  --gzip \
  --drop

适合：

  1. 小数据集；
  2. 单库单集合；
  3. 跨版本导出；
  4. 开发环境。

限制：

  1. 大集合耗时长；
  2. 默认不是持续时间点备份；
  3. 恢复需要重建索引；
  4. 对在线集群有读压力；
  5. 不适合超大规模全量。

22.4 快照备份

文件或云盘快照要求捕获一致时间点：

flush or coordinate filesystem snapshot
  -> snapshot data volume
  -> include journal
  -> record oplog position

常见策略：

  1. 备份节点快照；
  2. 云盘崩溃一致性快照；
  3. 文件系统冻结；
  4. 与官方工具结合；
  5. 分片集群统一时间点。

优点是恢复快、适合大数据量；限制是依赖存储平台和拓扑一致性。

22.5 延迟副本

Delayed Secondary 可以提供逻辑延迟：

cfg = rs.conf()
cfg.members[2].hidden = true
cfg.members[2].priority = 0
cfg.members[2].secondaryDelaySecs = 3600
rs.reconfig(cfg)

适合：

  1. 误更新恢复；
  2. 快速查看历史状态；
  3. 应急取证。

限制：

  1. 不是备份；
  2. 硬件故障无法保护；
  3. 延迟窗口有限；
  4. 不能替代异地备份。

22.6 时间点恢复

思路：

restore snapshot at T0
  -> replay oplog to T1
  -> stop before wrong operation

要求：

  1. 快照时间点记录；
  2. oplog 覆盖 T0 到 T1；
  3. 恢复目标时间明确；
  4. 在隔离环境执行；
  5. 恢复结果通过业务校验。

误删除恢复不要直接覆盖生产，应先恢复临时集群导出数据。

22.7 恢复演练

流程：

provision isolated cluster
  -> restore metadata
  -> restore data
  -> start service
  -> verify users
  -> verify indexes
  -> count collections
  -> sample business keys
  -> test read and write
  -> measure RTO

验收：

  1. 文档数；
  2. 索引数；
  3. 用户角色；
  4. 副本集状态；
  5. 分片路由；
  6. 关键业务查询；
  7. 恢复时间；
  8. 备份完整性日志。

22.8 备份安全

要求：

  1. 备份文件加密；
  2. 访问权限最小化；
  3. 与生产不同账号管理；
  4. 异地保存；
  5. 传输加密；
  6. 保留策略合规；
  7. 删除审批；
  8. 备份系统纳入审计。

22.9 常见问题

问题 原因
恢复后无用户 未备份 admin 库
分片路由错误 Config Server 未恢复
索引缺失 mongorestore 元数据异常
时间点无法恢复 oplog 覆盖不足
快照不一致 journal 未包含或时间点错
恢复慢 数据量大、索引重建

本章小结

MongoDB 备份要根据 RPO/RTO 选择 mongodump、快照、持续备份或组合方案。分片集群必须备份 Config 元数据，恢复必须演练并验证路由、用户、索引和业务数据。延迟副本是应急手段，不是完整备份。

思考题

  1. 为什么分片集群必须备份 Config Server？
  2. mongodump 适合什么规模？
  3. 快照为什么要包含 journal？
  4. 延迟副本为什么不能替代备份？
  5. 时间点恢复需要哪些条件？