在 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天）；重要备份可异地/云存储二次拷贝。
- 安全与合规
- 备份文件与凭据最小权限访问；开启审计日志与备份成功/失败告警；定期演练与审计恢复流程。
