MongoDB 备份与恢复

内容：原理、工具、方案选择、实操命令、常见坑

MongoDB 备份的核心目标

防误删 / 防误操作
防节点故障 / 磁盘损坏
支持时间点恢复（PITR）
不影响线上业务

一、MongoDB 备份方式总览（重点）

方式	是否一致	是否支持 PITR	影响性能	适用场景
mongodump	逻辑一致	❌	中	小数据量
文件系统快照	强一致	⚠️	低	生产主流
Oplog	增量	✅	极低	时间点恢复
云厂商备份	强一致	✅	极低	云环境
MongoDB Atlas	强一致	✅	极低	托管

👉 生产推荐：快照 + Oplog

二、mongodump / mongorestore（最常用）

1️⃣ mongodump（逻辑备份）

示例

mongodump \
  --host 127.0.0.1 \
  --port 27017 \
  --db mydb \
  --out /backup/mongo

特点

✅ 简单
❌ 数据量大时慢
❌ 备份期间数据可能变化（非强一致）

2️⃣ mongorestore（恢复）

mongorestore \
  --db mydb \
  /backup/mongo/mydb

常用参数：

--drop        # 先删除集合
--nsInclude   # 指定 namespace
--gzip        # 配合压缩

⚠️ mongodump 的坑

数据 > 100GB 不推荐
对分片集群只备份 config / 单 shard 不完整
不支持时间点恢复

三、Oplog 备份（PITR 核心）

1️⃣ 什么是 Oplog

MongoDB 复制集的操作日志
记录每一次写操作

📌 只存在于 Replica Set

2️⃣ 备份 Oplog

mongodump \
  --db local \
  --collection oplog.rs \
  --out /backup/oplog

3️⃣ 使用 Oplog 恢复到某一时间点

mongorestore \
  --oplogReplay \
  /backup

👉 实现：

全量备份 + Oplog 回放 = 时间点恢复

四、文件系统快照（生产首选）

1️⃣ 原理

使用 LVM / 云磁盘快照
备份 WiredTiger 数据文件

2️⃣ 标准流程（非常重要）

fsyncLock（锁写）
做磁盘快照
fsyncUnlock

示例

db.fsyncLock()
# 做快照
db.fsyncUnlock()

3️⃣ 优点

✅ 强一致
✅ 极快
✅ 对业务影响小

4️⃣ 注意

必须是副本集节点
推荐在 secondary 上做

五、分片集群备份

❌ 错误做法

只备份某一个 shard

✅ 正确做法

需要备份：

所有 shard
config server

推荐方案

停止 balancer
所有节点同一时间点快照

sh.stopBalancer()
# 备份
sh.startBalancer()

六、MongoDB 恢复场景分类

1️⃣ 单库 / 单集合误删

mongorestore --nsInclude mydb.users

2️⃣ 整库恢复

mongorestore --drop /backup/mongo

3️⃣ 恢复到某个时间点（PITR）

全量备份 -> 回放 oplog 到指定时间

4️⃣ 新集群迁移恢复

关闭原集群写入
全量备份
新集群 restore
切流量

七、自动化备份最佳实践（强烈推荐）

1️⃣ 备份策略

每日全量
Oplog 每 5~10 分钟
保留 7~30 天

2️⃣ 备份位置

本机 ❌
远程存储 ✅
对象存储（S3 / OSS）✅

3️⃣ 校验机制

定期 restore 到测试库
校验备份完整性

八、常见故障 & 坑

❌ 只备份 primary

👉 primary 挂了，备份不可用

❌ 忘记 oplog

👉 只能恢复到备份时间点

❌ dump 分片集群不完整

👉 数据缺失

❌ 备份在业务高峰

👉 主从延迟、业务抖动

九、总结

MongoDB 的生产级备份方案是：

副本集 + Secondary 节点 + 磁盘快照 + Oplog 增量回放，mongodump 只适合小规模或应急备份。