Ubuntu 上 MongoDB 数据恢复方法概览
在 Ubuntu 上，MongoDB 数据恢复可按场景分为：有备份的常规恢复、利用复制集或 Oplog 的时间点恢复、文件系统快照恢复，以及极端情况下的 WiredTiger 底层文件修复。下面给出每种方法的适用场景与关键命令，便于快速选型与操作。
一、有备份时的标准恢复（mongodump mongorestore）
- 适用：已有 mongodump 生成的 BSON 备份，需恢复到本机或迁移到新环境。
- 步骤与命令：
- 准备环境：确认 MongoDB 服务已停止（避免并发写入），必要时先对现有数据做一次临时备份。
- 恢复全库或指定库/集合：
- 全库：mongorestore /path/to/backup/2025-08-01/
- 指定库：mongorestore --db mydb /path/to/backup/2025-08-01/mydb
- 指定集合：mongorestore --db mydb --collection mycol /path/to/backup/2025-08-01/mydb/mycol.bson
- 覆盖写入：可加 --drop 先删除同名集合再恢复（谨慎）。
- 校验：启动服务后连接 mongo shell，检查集合计数与样本数据。
- 说明：mongodump/mongorestore 保留 BSON 类型与索引元信息，适合迁移与一致性恢复。
二、时间点恢复与复制集场景
- 适用：部署为 副本集 且已捕获 Oplog，需要将数据恢复到故障前的某一时刻。
- 基本流程：
- 在备份中包含 oplog（例如使用 --oplog 选项或专用 Ops Manager/Atlas 备份），得到基准全量 + oplog 集合。
- 恢复到目标时间点：mongorestore --oplogReplay /path/to/backup/，如仅需某库/集合可配合 --nsInclude。
- 无专用备份时，可从 其他副本集成员 重新同步或提升为 Primary 以继续提供服务。
- 说明：Oplog 回放可实现精确时间点恢复，是生产环境常用的容灾手段。
三、文件系统快照与增量备份恢复
- 文件系统快照（LVM/ZFS 等）：
- 适用：数据量大、要求快速时间点恢复；在停机窗口对 dbPath 所在卷做快照，恢复时回滚到快照点。
- 要点：确保快照一致性（建议短暂停写或置于维护窗口），快照完成后按快照恢复数据目录并启动服务。
- 增量备份：
- 适用：频繁变更场景；结合 全量 + 增量（如 oplog） 策略，缩短恢复窗口与存储占用。
- 恢复：先恢复最近一次全量，再按时间顺序回放增量/Oplog 至目标时刻。
四、无备份时的底层文件修复（WiredTiger 文件级打捞）
- 适用：数据目录或 collection-*.wt 等 WiredTiger 文件损坏/误删，且无法通过常规备份恢复。
- 思路与关键步骤（高风险，务必只读操作并先做镜像）：
- 准备同版本的 WiredTiger 工具，将相关文件（如 collection-.wt、_mdb_catalog.wt、WiredTiger 等）拷贝到独立目录。
- 使用 wt salvage 对损坏集合文件进行“打捞”：
- ./wt -v -h /path/to/dump -C “extensions=[./ext/compressors/snappy/.libs/libwiredtiger_snappy.so]” -R salvage collection-xxx.wt
- 将打捞后可读取的数据导出为 dump：
- ./wt -v -h /path/to/dump -R dump -f collection.dump collection-xxx
- 启动临时 mongod（如：mongod --dbpath tmp-mongo --storageEngine wiredTiger --nojournal），在临时库中创建同名空集合并清空，再将 dump 重新导入。
- 校验后导出并迁移到正式实例，必要时重建索引与校验约束。
- 说明：该方法依赖 WiredTiger API，仅建议由有经验的 DBA 在充分评估与备份镜像后尝试。
五、实践建议与注意事项
- 恢复前尽量停止写操作或切换到维护模式，避免恢复过程产生新写入冲突。
- 任何恢复操作前先做现有数据/环境的备份，以便回滚。
- 恢复后用 集合计数、抽样查询、索引与约束校验 多维度验证数据一致性与可用性。
- 对关键业务，建议常态化配置 副本集 + Oplog，并使用 Ops Manager/Atlas 或脚本化的 全量 + 增量 策略，定期演练恢复流程以验证 RPO/RTO。