进入最后一个阶段——运维与架构。这一篇讲备份恢复，它是数据库运维里最不能省的一环。前面讲了那么多高可用、持久化机制，都是为了「正常运行时不丢数据」，但备份应对的是「极端情况下怎么把数据救回来」——误删整个集合、灾难性故障、需要回到某个时间点。

先把机制边界说清楚

MongoDB 的备份主要有三种方式：

  • mongodump（逻辑备份）：把数据导出成 BSON/JSON 逻辑格式。跨版本、跨架构，但大集合慢。
  • 文件级快照（物理备份）：对数据目录做文件系统/云盘快照。快，适合大数据，但同版本恢复。
  • oplog 点恢复（PITR）：快照 + oplog 回放，恢复到任意时间点。

这三种不是二选一，而是配合使用：生产主备份用快照（快、全量），mongodump 用于迁移和单集合导出，PITR 用于误操作挽回。

三种备份姿势对比

备份恢复：三种姿势

mongodump 是最简单的逻辑备份工具。它连接 mongod，把集合数据导出成 BSON 文件。优点是跨版本跨架构（导出的逻辑数据可以在不同 MongoDB 版本恢复），适合小数据、单库/单集合备份、跨环境迁移。缺点是大集合很慢（要全表扫描导出），且备份过程占用 mongod 资源，影响生产。所以生产环境的全量备份不建议用 mongodump，它更适合辅助场景。

文件级快照是生产主备份的推荐方式。它利用文件系统（如 LVM）或云盘的快照能力，对数据目录做瞬时快照——只复制元数据，秒级完成，不占用 mongod 资源。配合 journal，快照是一致的（journal 保证数据文件可恢复）。恢复时把快照的数据目录挂回去即可。缺点是要求同版本同架构恢复，且依赖文件系统/云盘支持快照。

快照应该在 Secondary 上做，避免影响 Primary。从 Secondary 快照还能保证 Primary 的写入不受干扰。

**oplog 点恢复（PITR）**是最强的恢复能力。它结合快照和 oplog：先恢复到某个快照点，再回放快照之后的 oplog 到指定时间戳。这样能恢复到任意时间点，用于挽回误操作（误删集合、误改数据）。代价是操作复杂，且依赖 oplog 的保留窗口（oplog 是环形的，太旧的会被覆盖）。

备份策略

把三种方式组合成生产备份策略：

  • 主备份：定期（如每天）从 Secondary 做文件级快照。这是全量、一致、快速的备份。
  • 增量：快照之间的数据变更由 oplog 覆盖（oplog 保留窗口要足够长，至少覆盖两次快照间隔）。
  • PITR 能力：保留多个时间点的快照 + 足够的 oplog，保证能恢复到近期任意时间。
  • 辅助：mongodump 用于单集合导出、跨环境迁移、版本升级前的逻辑备份。
  • 异地：备份要存到异地（对象存储、异地机房），防止单点灾难。

备份的两个关键指标：

  • RPO（Recovery Point Objective）：能容忍丢失多久的数据。RPO 越小，备份越频繁。日快照 RPO 是一天，配合 oplog PITR 可以做到秒级 RPO。
  • RTO（Recovery Time Objective）：多久能恢复。快照恢复快（分钟级），mongodump 恢复慢（看数据量）。

恢复演练：比备份更重要

这是备份运维最关键、也最被忽视的一点：没演练过的备份等于没备份。很多团队定期备份，但从没试过恢复，等真出事时才发现备份是坏的、恢复步骤缺失、依赖的环境不存在。

恢复演练要定期做（至少每季度）：

  1. 拿一个备份，在测试环境完整恢复一次。
  2. 验证恢复的数据完整性（记录数、抽查关键数据）。
  3. 记录恢复的完整步骤和耗时（这是 RTO 的实测值）。
  4. 验证应用能连上恢复后的数据库正常工作。

演练发现的任何问题（备份损坏、步骤遗漏、耗时超标），都要在真出事前解决。备份的价值，只在「能成功恢复」时才兑现。

分片集群的备份

分片集群备份更复杂：

  • mongodump 可以连 mongos 备份（逻辑导出全集群），但大集群慢。
  • 文件级快照要协调所有 shard 同时快照（保证一致性），config server 也要备份。
  • 通常用专门的备份工具（如 MongoDB Atlas Backup、Percona Backup）处理分片集群的一致性备份。

判断框架

  • 生产主备份用文件级快照（从 Secondary），快、一致、全量。
  • mongodump 用于迁移、小数据、单集合，不用于生产全量。
  • PITR = 快照 + oplog 回放，恢复到任意时间，挽回误操作。
  • 从 Secondary 备份，不影响 Primary。
  • 备份要异地存放，防单点灾难。
  • 定期恢复演练——没演练的备份不算数。
  • RPO/RTO 决定备份频率和方式，按业务容忍度设计。

下一篇讲 Change Stream，把 MongoDB 的事件驱动能力补上。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按运维和架构选型这条线更新。

十三Tech公众号二维码