mongodump可直接按库/集合备份，Python仅作调度上传胶水层；需用cron定时、绝对路径调用、显式重定向日志、校验返回码与文件大小，并实施本地7天+云盘30天清理及定期恢复验证。
用 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）。
上传云盘环节注意：
立即学习“Python免费学习笔记（深入）”；
- 阿里云 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 导出——但这会增加复杂度，多数日志类集合其实可以接受几秒误差。
