备份与恢复
MongoDB 的备份目标是保存一个可恢复的一致数据状态，并在需要时恢复到指定时间。复制集只保存当前数据副本，不能代替能够隔离误操作、恶意删除和集群级损坏的历史备份。
备份方式
| 方式 | 特点 | 适用边界 |
|---|---|---|
mongodump / mongorestore | 逻辑导出 BSON 与元数据，便于选择 Database/Collection | 大数据量耗时长，不是物理页级备份 |
| 文件系统快照 | 快速保存数据文件时间点 | 必须保证数据文件、Journal 与多个卷之间一致 |
| 复制集节点快照 | 可在 Secondary 降低 Primary 影响 | 仍需记录 Oplog 和快照一致点 |
| 托管连续备份 | 自动快照并结合 Oplog 支持时间点恢复 | 能力、保留期和恢复粒度取决于服务配置 |
复制集备份需要考虑写入持续发生时各文件或各 Shard 的一致性。简单复制正在运行的 dbPath 不等于有效热备份。
恢复范围
| 目标 | 所需能力 |
|---|---|
| 恢复某个 Collection | 逻辑备份或独立的数据修复流程 |
| 恢复整个 Replica Set | 完整快照、配置和重新建立成员 |
| Point-in-Time Recovery | 基础备份加连续的 Oplog 历史 |
| Sharded Cluster 一致恢复 | 各 Shard 与 Config Server 的协调备份和统一恢复点 |
Oplog 是循环覆盖的，当前 Oplog Window 不天然满足长期恢复保留。需要 PITR 时必须由备份系统持续捕获所需变化。
恢复验证
备份完成不代表能够恢复。恢复演练应验证：
- 备份文件、密钥和配置是否完整可读。
- 恢复后的 Document 数量、关键业务聚合和索引是否正确。
- 用户、角色、认证机制和连接配置是否可用。
- Replica Set、Shard、Config Server 元数据是否形成正确拓扑。
- 实际恢复耗时是否满足 RTO，目标时间是否满足 RPO。
备份应复制到独立账户或故障域，并设置不可变或最小删除权限，避免数据库凭据泄露时备份同时被删除。