1. 课程导入与体系概览

在真实生产环境中，MongoDB 的可用性从来不是“数据库自己不出问题”这么简单。硬件故障、误删集合、索引重建失败、机房断电、勒索软件加密、跨区域网络抖动，任何一类事件都可能让业务在几分钟内失去读写能力。备份恢复与容灾体系要解决的核心问题只有一个：当数据或服务发生不可逆损失时，能否在可接受的时间内、以可接受的数据损失量，把业务重新拉回可用状态。

这句话里包含两个必须被量化的目标：RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。RTO 回答“业务能容忍停多久”，RPO 回答“业务能容忍丢多少数据”。例如某订单系统要求 RTO ≤ 30 分钟、RPO ≤ 5 分钟，那么备份策略、oplog 保留窗口、副本集部署方式和恢复演练频率都必须围绕这两个数字反推，而不是先买存储再想目标。

理解这套体系，需要先建立几个关键术语的准确含义。逻辑备份指以 BSON/JSON 形式导出数据，典型工具是 mongodump，产物可读、可跨大版本迁移，但恢复大库时速度慢、索引需重建。物理备份直接复制 WiredTiger 数据文件与 journal，典型方式是文件系统快照或 mongod 停止后的冷拷贝，恢复快、体积小，但对版本和存储引擎一致性要求高。oplog（操作日志）是副本集特有的 capped collection，记录所有写操作，是增量备份和时间点恢复（PITR）的基础。副本集（Replica Set）通过多节点数据冗余提供自动故障转移，解决的是“节点级高可用”，但它不能防止误删——误删会同步到所有节点。分片集群（Sharded Cluster）把数据分布到多个 shard，容灾时必须同时考虑每个 shard 的副本集和 config server 的备份。时间点恢复（Point-in-Time Recovery）则是“全量备份 + oplog 重放”的组合，把数据恢复到某个精确时刻，是应对误操作最有效的手段。

从整体架构看，一套完整的 MongoDB 容灾体系可以拆成四层。第一层是数据保护层：全量备份、增量 oplog、快照，决定 RPO。第二层是存储与隔离层：备份文件放在哪里、是否异地、是否不可变（WORM），决定能否抵御勒索和机房级灾难。第三层是恢复与切换层：恢复流程、副本集选举、跨区域提升，决定 RTO。第四层是验证与治理层：定期恢复演练、备份完整性校验、监控告警，决定这套体系是否“真的能用”。很多团队前三层都做了，却因为从不演练，在真正故障时发现备份损坏或恢复脚本早已失效。

把四层串起来看，学习路径也就清晰了。建议按“先会用工具，再懂原理，最后建体系”的顺序推进：先掌握 mongodump/mongorestore 的基本用法和常见参数，理解 oplog 的结构与重放机制；然后进入副本集与分片集群的备份策略设计，学会区分全量、增量、快照的适用场景；接着处理跨机房、跨云容灾和 PITR 的工程细节；最后落到演练、监控和治理，把 RTO/RPO 从纸面指标变成可验证的工程能力。

本课程后续章节会围绕这条主线展开，每一节都会给出可操作的命令、参数示例和判断依据。需要强调的是，文中出现的所有参数值、时间窗口和容量数字，除非特别说明，均为教学示例或合理假设，实际落地时必须结合你的数据量、写入速率、网络带宽和合规要求重新测算。例如 oplog 保留窗口，不能只看“默认大小”，而要用 db.getReplicationInfo() 观察 oplog 时间跨度，确保它覆盖两次全量备份之间的间隔，否则 PITR 会在窗口外断裂。

接下来，我们会从最基础的备份工具讲起，逐步搭建起一套可演练、可度量、可演进的 MongoDB 容灾体系。