从 MongoDB Atlas 迁到自托管副本集后，Prochesta 省了钱却丢了 Atlas 自带的持续备份。生产数据落在单台 VPS 上，没有快照、没有异地副本，一次误删或坏盘就是灭顶之灾。他们真正需要的不是"备份数据库"，而是恢复到任意时间点——夜间快照救不了 14:20 发生的损坏。
选型时他们先排除了自研的 mongopit（基于 mongodump --oplog 与 oplog 回放），因为存储目标是 Cloudflare R2 而非 Google Drive。R2 零出口流量费让恢复演练成本为零，S3 语义也比 Drive 的文件同步更适合无人值守的夜间任务。最终选了 Percona Backup for MongoDB（PBM），但 MongoDB Community 没有 $backupCursor 聚合阶段，PBM 只能做逻辑备份：主节点承担备份 CPU 开销，恢复时间随数据量增长快于备份时间。
架构上 dev 与 prod 共用同一个 R2 bucket，靠 key 前缀隔离，引导脚本会校验 PBM 实际写入的前缀，配置错误直接中止。保留策略为 7 天全量快照加 2 天每 10 分钟的 oplog 切片，两小时内可恢复到任意瞬间。监控没用 Percona 自带的 exporter，而是每 5 分钟解析 pbm status 写入 Prometheus textfile，用时间戳停滞作为死信开关，15 分钟无更新即告警。
上线踩了四个坑：空密码的 agent 拖垮整个部署、setup 脚本保留旧 feature flag 导致静默跳过、PBM 2.15 返回带括号的配置值导致前缀校验失败、restore 在无 TTY 管道里因确认提示直接退出。每个 bug 都在运维脚手架而非备份引擎本身。
首份生产备份 74.98 MB 对应 517 MB 数据目录，逻辑备份只带文档不带存储，索引在恢复时重建，journal 和 oplog 属于工作状态。尚未解决的是自动化恢复验证——目前没有定时把最新备份恢复到临时实例并校验集合计数，PBMBackupSizeCollapsed 告警只是粗糙的替代品。备份与 API 容器共享 R2 凭据，任何持有该 key 的进程都能删光备份，R2 又没有对象版本化兜底，预留了独立 PBM_R2_* 密钥的切换位。
#开发者 #工具 #MongoDB #Percona #PBM #CloudflareR2 #DevOps #数据库备份 #Prochesta
@DevToolboxHub