在 CentOS 上制定 MongoDB 备份策略
一 策略总览与 RPO/RTO
- 明确目标:结合业务确定可接受的RPO(恢复点目标)与RTO(恢复时间目标)。例如:每日全量+保留7–14天可将 RPO 控制在≤24小时;若需更细粒度,应引入增量/时间点恢复能力。
- 方法选型与适用场景:
- mongodump(逻辑备份):易用、灵活,适合小型到中型数据库或开发/测试环境;对性能有一定影响,建议避开高峰或改为在从节点执行。
- 文件系统快照(LVM/XFS 等):速度快、影响小,适合大型数据库;需底层存储支持,恢复流程相对复杂。
- oplog 增量/时间点恢复:基于 oplog 重放,适合需要连续备份与任意时间点恢复的场景;部署与恢复复杂度较高。
- MongoDB Cloud Manager/Ops Manager:企业级方案,支持连续备份与时间点恢复;Cloud Manager 面向云托管,Ops Manager 为本地部署,两者均需 MongoDB Enterprise。
- 第三方工具(如 Percona Backup for MongoDB):提供增量/加密/压缩等高级能力,需额外部署与运维。
二 在 CentOS 上的落地方案
- 方案A 逻辑备份(mongodump + cron)
- 适用:通用性强、成本低的全量备份;建议配合保留策略与压缩使用。
- 示例(全库):
- 命令:mongodump --host 127.0.0.1 --port 27017 --out /backups/mongodb/$(date +%F_%H-%M-%S) --gzip
- 保留:find /backups/mongodb -type f -mtime +14 -delete
- 自动化脚本要点(示例):创建目录、执行 mongodump、压缩归档、记录日志、清理N天前备份;通过 crontab 定时执行(如每天02:00)。
- 方案B 文件系统快照(LVM 示例)
- 适用:追求高性能与快速恢复的生产环境;建议对包含 dbPath 的卷做快照,并在从节点执行以减少业务影响。
- 基本流程:
- 冻结/静默(WiredTiger 建议):db.fsyncLock()
- 创建快照:lvcreate -s -L 10G -n mongodb_snap /dev/vg0/mongodb_lv
- 解除冻结:db.fsyncUnlock()
- 用快照挂载只读副本,再用 mongodump 导出或拷贝数据文件;保留期内定期快照,过期删除。
- 方案C 企业级与云方案
- Cloud Manager/Ops Manager:部署/接入后自动读取 oplog,按策略持续备份并支持时间点恢复;适合副本集/分片集群与合规要求较高的场景。
三 备份脚本与定时任务示例
- 目标:全库备份、压缩归档、保留14天、记录日志、cron 定时执行。
- 示例脚本(/usr/local/bin/mongo_backup.sh):
- 内容:
- #!/usr/bin/env bash
set -Eeuo pipefail
BACKUP_ROOT=“/backups/mongodb”
TIMESTAMP=$(date +“%F_%H-%M-%S”)
OUT_DIR=“$BACKUP_ROOT/$TIMESTAMP”
LOG_FILE=“$BACKUP_ROOT/backup_$TIMESTAMP.log”
RETENTION_DAYS=14
mkdir -p “$OUT_DIR”
echo “[$(date)] Start backup to $OUT_DIR” >> “$LOG_FILE”
mongodump --host 127.0.0.1 --port 27017 --out “$OUT_DIR” --gzip >> “$LOG_FILE” 2>&1
tar czf “$OUT_DIR.tar.gz” -C “$BACKUP_ROOT” “$(basename “$OUT_DIR”)” && rm -rf “$OUT_DIR”
echo “[$(date)] Backup finished: $OUT_DIR.tar.gz” >> “$LOG_FILE”
find “$BACKUP_ROOT” -name “*.tar.gz” -mtime +“$RETENTION_DAYS” -delete >> “$LOG_FILE” 2>&1
- 定时任务(/etc/crontab):
- 0 2 * * * root /usr/local/bin/mongo_backup.sh
- 安全建议:避免在脚本中硬编码账号密码;可使用凭据文件或 X.509 认证,并限制备份目录权限(如 700)。
四 恢复流程与验证
- 逻辑备份恢复(mongorestore)
- 全库:mongorestore --gzip /backups/mongodb/2025-08-01_02-00-00.tar.gz
- 单库:mongorestore --gzip --db mydb /backups/mongodb/2025-08-01_02-00-00/mydb
- 覆盖导入:加 –drop(谨慎使用,会先删除目标库同名集合)。
- 时间点恢复思路
- 具备 oplog 的副本集/集群:先恢复到最近一次全量/快照,再重放 oplog 至目标时间点(Cloud Manager/Ops Manager 可图形化完成;自建环境需按 oplog 位点与时间窗口执行)。
- 验证与演练
- 定期做恢复演练与备份完整性校验(如抽样 mongorestore --dryRun、校验文件大小/数量/校验和);记录RTO/RPO 指标并复盘优化。
五 关键注意事项与优化
- 性能与影响
- 尽量在从节点或低峰时段执行备份;mongodump 可通过 –numParallelCollections 增加并行度,权衡对数据库负载的影响。
- 一致性与加密
- 逻辑备份建议配合 oplog 实现增量/时间点能力;使用 WiredTiger 时可短暂 fsyncLock 提升一致性(注意业务暂停窗口)。
- 使用 AES256-GCM 的加密存储引擎:从热备份恢复可自动轮换密钥避免 IV 重用;从冷备份恢复需在启动 mongod 时增加 –eseDatabaseKeyRollover 以避免密钥重用风险。
- 存储与保留
- 预估备份容量(全量大小≈数据规模,压缩后通常更小),监控磁盘使用率并设置合理保留周期(如7–14天);重要备份可异地/云存储二次拷贝。
- 安全与合规
- 备份文件与凭据最小权限访问;开启审计日志与备份成功/失败告警;定期演练与审计恢复流程。