最可靠的方式是用 mongodump 工具直接导出数据库，Python 仅负责调用、路径组织、时间戳处理和旧备份清理；需显式指定认证参数、使用 --gzip 和 --archive、统一 UTC 时间命名、保留 N 份备份而非按天数删除，并注意一致性验证限制。
用 mongodump 命令直接导出数据库最可靠
Python 本身不提供 MongoDB 备份能力，真正干活的是 MongoDB 自带的 mongodump 工具。Python 只负责调用它、组织路径、处理时间戳和清理旧备份。别试图用 PyMongo 手动遍历 collection 导出 JSON —— 容易丢元数据（如 ObjectId、日期类型）、不支持 GridFS、无法保证原子性。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 确保系统 PATH 中已包含
mongodump（通常随 MongoDB Server 或 MongoDB Database Tools 安装） - 用
subprocess.run()调用，别用os.system()—— 方便捕获错误码和 stderr - 必须显式指定
--uri或--host+--port+--username+--password，避免凭据硬编码在命令行里（会被ps看见） - 加
--gzip和--archive生成单个压缩文件，比默认目录结构更易归档和传输
用 schedule 库写定时任务比 Cron 更易调试
如果你只在开发机或轻量服务器上跑，Python 的 schedule 比系统 Cron 更直观：逻辑全在代码里，可加日志、断点、异常重试。但注意它不是守护进程 —— 进程退出就停了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 不要用
time.sleep()轮询，schedule内部已做精准等待 - 用
schedule.every().day.at("02:00")比every(24).hours更可控（避免上次备份卡住导致偏移） - 每次执行前检查
mongodump是否可用：shutil.which("mongodump") - 备份失败时发邮件或写入本地告警文件，别只 print —— 后台运行时看不到 stdout
备份文件名必须含时间戳且避免时区歧义
用 datetime.now().strftime("%Y%m%d_%H%M%S") 生成文件名看似简单，但容易踩坑：如果服务器时区是 UTC 而你按北京时间看日志，会发现“昨天”的备份实际是“今天凌晨”。更糟的是，如果备份脚本被跨时区机器调用，文件名可能重复或乱序。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 统一用 UTC 时间生成文件名：
datetime.utcnow().strftime("%Y%m%dT%H%M%SZ")（末尾 Z 是 ISO 8601 标准） - 文件名中不要出现空格、中文、冒号（
:在 Windows 下非法），用下划线或连字符替代 - 完整路径示例：
/backup/mongo/myapp_20240520T020000Z.archive.gz - 备份前先
os.makedirs(backup_dir, exist_ok=True)，别假设目录一定存在
自动清理旧备份要按“保留 N 份”而非“删除 X 天前”
按天数清理（如“删 7 天前的”）在备份失败时会导致空白期 —— 比如连续两天失败，第三天成功后，立刻删掉唯一一份有效备份。更稳妥的是保留最近 N 份，不管它们跨度多大。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
glob.glob(f"{backup_dir}/*.archive.gz")获取所有备份文件 - 按文件名中的时间戳排序（字符串排序对
YYYYMMDDTHHMMSSZ格式天然有效） - 留最新
N个，其余os.remove()—— 注意权限问题，尤其当备份由 root 启动但清理脚本非 root 时 - 清理前加
if len(files) > keep_count:判断，避免误删
真正的难点不在调度或压缩，而在于备份一致性验证 —— mongodump 默认不锁库，高写入场景下可能导出不一致快照。若业务要求强一致性，得配合 --oplog 和 mongorestore --oplogReplay，但这需要副本集且开启 oplog，不是单节点能解决的。
