Python自动备份MongoDB到云盘教程

本文深入解析了如何构建一套可靠、可维护的MongoDB自动化备份体系，强调核心备份动作应交由原生工具mongodump完成，而Python仅作为轻量级调度与云盘上传的“胶水层”，避免重复造轮子；教程涵盖从手动验证命令、认证参数配置、路径与时间格式细节，到cron定时执行、绝对路径调用、日志重定向、返回码与文件大小双重校验，再到本地7天+云盘30天智能清理及强制恢复验证等生产级实践要点，直击运维中易被忽视却致命的坑——如权限缺失、目录未预创建、跨平台压缩不兼容、cron环境变量差异、备份一致性边界等，为开发者提供一条兼顾简洁性、健壮性与可扩展性的落地路径。

用 mongodump 每天导出指定集合最直接

不用写 Python 脚本也能完成核心备份动作——mongodump 命令原生支持按库、按集合导出，且输出为 BSON+JSON 结构，恢复时兼容性好。关键不是“用不用 Python”，而是“谁来调度 + 谁来上传”。Python 在这里更适合做胶水层，而不是替代 mongodump。

实操建议：

• 先手动跑通命令：例如备份 mydb 库里的 logs 集合：

  mongodump --host localhost:27017 --db mydb --collection logs --out /backup/mongo/$(date +\%Y\%m\%d)

• --out 路径必须是目录，不能是文件名；日期格式里 % 要转义（bash 中写成 \%Y\%m\%d）
• 如果 MongoDB 启用了认证，必须加 --username、--password、--authenticationDatabase，漏掉任一参数都会报 Failed: error getting collections: not authorized
• 导出结果是 /backup/mongo/20240520/mydb/logs.bson 和 .json 两个文件，后者含元数据（如 ObjectId、时间戳类型），别只传 .bson

Python 负责打包、压缩、上传云盘，别硬扛导出逻辑

Python 的优势在文件操作和 API 调用，不是 BSON 序列化。用 subprocess.run() 调 mongodump 更稳，比用 pymongo 自己遍历游标再写文件更少出错、内存占用更低、还能继承 mongodump 的压缩选项（--gzip）。

上传云盘环节注意：

• 阿里云 OSS、腾讯 COS、七牛 Kodo 都提供 Python SDK，但上传前必须确认目标路径权限：OSS 默认不自动创建多级目录，upload_file('backup/logs_20240520.tar.gz', 'mongo-backup/2024/05/logs_20240520.tar.gz') 中的 mongo-backup/2024/05/ 要提前存在或用 SDK 的 put_object 手动建空对象模拟目录
• 本地打包建议用 tarfile + gzip，别用 shutil.make_archive：后者在 Linux 下默认调用 tar，但 Windows 下会 fallback 到 zip，导致跨平台解压失败
• 上传前校验文件大小：如果 os.path.getsize(archive_path) == 0，大概率是 mongodump 执行失败但 Python 没捕获异常，需检查返回码

用系统 cron 而不是 Python 的 schedule 库来定时

Python 的 schedule 或 APScheduler 在进程退出后就停了，不适合长期后台运行；而系统级 cron 不依赖 Python 进程存活，重启机器后自动生效，还自带邮件告警（MAILTO=）。

典型 crontab 条目（每天凌晨 2 点执行）：

0 2 * * * cd /opt/mongo-backup && /usr/bin/python3 /opt/mongo-backup/backup_job.py >> /var/log/mongo-backup.log 2>&1

要注意：

• 脚本中所有路径写绝对路径，os.getcwd() 在 cron 下是 /root 或 /，不是你开发时的项目目录
• 环境变量不同：cron 默认只有 minimal PATH（通常不含 /usr/local/bin），mongodump 如果装在 brew 或自定义路径，要用绝对路径调用，例如 /usr/local/bin/mongodump
• 日志重定向必须显式写 2>&1，否则 stderr（比如连接拒绝、认证失败）不会进 log 文件，你只能看到“没反应”

备份保留策略和恢复验证不能省

每天全量备份集合，一个月就是 30 个包，没人会手动删。不设清理逻辑，磁盘迟早爆满；不验证恢复流程，真出事时才发现备份文件打不开。

最小可行方案：

• 本地保留最近 7 天：用 find /backup/mongo -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +（加到 cron 里，放在备份命令之后）
• 云盘上保留最近 30 天：OSS 支持生命周期规则（Lifecycle），配置前缀 mongo-backup/、过期天数 30，比代码删更可靠
• 每月抽样一次恢复测试：选一个旧备份包，mongorestore --drop --host localhost:27017 --db mydb_restore /backup/mongo/20240401/mydb/，然后查 db.logs.countDocuments({}) 看数量是否合理

最容易被忽略的是时间戳一致性：mongodump 导出期间集合可能还在写入，导致备份里混入部分新数据、部分旧数据。如果业务要求强一致性，得配合 fsyncLock（仅 WiredTiger 引擎支持）或副本集从 secondary 导出——但这会增加复杂度，多数日志类集合其实可以接受几秒误差。

理论要掌握，实操不能落！以上关于《Python自动备份MongoDB到云盘教程》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！