Ubuntu 上 MongoDB 数据恢复技巧
一 常规恢复流程与要点
- 使用 mongodump/mongorestore 进行逻辑恢复：mongodump 生成的 BSON 能完整保留 索引与数据类型，适合迁移与整机恢复。示例：备份为 mongodump --db newdb --out /var/backups/mongobackups/$(date +‘%m-%d-%y’)；恢复为 mongorestore --db newdb --drop /var/backups/mongobackups/01-20-16/newdb/。恢复时建议加上 –drop 以避免集合已存在导致的数据混合。为降低对业务影响，尽量在 低峰时段 执行，并避免备份过程中写入导致的一致性偏差。若需定期执行，可用 cron 调度，并注意在 cron 中对 % 进行转义（如 date +‘%m-%d-%y’）。
二 时间点恢复与 oplog 回放
- 若部署了 副本集 并启用了 oplog，可通过 oplog 实现时间点恢复：先获取最近一次全量备份，再回放从该时间点之后的 oplog 到目标实例。常见做法是先用 mongodump 获取全量，再用 mongorestore 的 –oplogReplay 回放增量（需提供包含 oplog 的 dump 目录）。注意：仅 副本集 具备 oplog，且时间点恢复通常要求备份与目标的 MongoDB 大版本一致，避免兼容性问题。
三 物理文件损坏或误删时的 WiredTiger 手工打捞
- 当 WiredTiger 数据文件（如 collection-*.wt）损坏或被误删，可尝试用 WiredTiger 工具链“打捞”：
- 准备最小必要文件集：目标集合的 .wt、以及 _mdb_catalog.wt、sizeStorer.wt、storage.bson、WiredTiger、WiredTiger.lock、WiredTiger.turtle* 等系统文件；
- 使用 wt salvage 对受损集合文件进行“抢救”，生成可读取的数据；
- 用 wt dump 将抢救后的集合导出为文本 dump；
- 启动一个临时的 mongod（如 mongod --dbpath tmp-mongo --storageEngine wiredTiger --nojournal），在目标库先创建同名空集合并清空，再用 wt load 将 dump 导回；
- 校验数据后，用 mongodump 重新导出，再按常规流程恢复到正式实例。该方法依赖文件级可用性与 WiredTiger 版本匹配，操作前务必对现场文件做只读拷贝。
四 云数据库备份到自建环境的恢复
- 若数据来自云数据库 MongoDB 的备份，常见路径为：
- 逻辑备份恢复至自建库：下载云侧的 逻辑备份（BSON），使用与云实例版本匹配的 mongorestore 导入；注意 旧版 mongorestore 可能无法兼容新版本 MongoDB，版本选择需谨慎。
- 物理备份恢复至自建库：适用于 副本集、且未开启 TDE、存储引擎为 WiredTiger/RocksDB 的场景。物理包可能为 .tar.gz 或 _qp.xb（xbstream）。xbstream 需在 Linux 下配合 Percona XtraBackup 与 qpress 解压；WiredTiger 可直接按配置启动单节点进行数据校验与导出。自建库版本需与云实例版本严格对应（如 4.2→4.2）。
五 实战建议与常见坑
- 版本与兼容：恢复目标的 MongoDB 大版本 需与备份来源一致；跨版本恢复常失败或不完整。
- 工具链匹配：使用与备份来源版本匹配的 mongorestore/mongod，避免因版本不兼容导致导入异常。
- 一致性优先：备份期间尽量 停止写入 或使用 副本集+oplog 做时间点恢复，避免业务写入造成的数据漂移。
- 资源与窗口：大数据量恢复会占用 CPU/内存/磁盘与网络，务必选择 低峰时段 并做好容量评估。
- 校验与回滚：恢复后用 count/doc 抽样/校验和 核验关键集合；重要场景建议先恢复到 临时实例 验证，再切换到生产。
- 安全与权限：确保备份文件与传输通道的 权限与加密，避免二次泄露。