摘要

  • MongoDB Atlas 的 Backup Compliance Policy 在项目层设定最低备份要求，既有和新增集群都受影响。角色再高，也不能随手删除保护中的快照，或缩短拍下之后的保留期限。
  • 受此政策保护的集群终止后，既有快照继续按政策保留。保护期与之后的额外保留期拥有不同删除规则，工作负载的退役日期也无法代替备份的到期日期。

先收走老板的橡皮擦

“项目所有者”是一个很容易让人产生权力幻觉的头衔。到了删备份这一步，MongoDB Atlas 会让这个头衔安静下来。

启用 Backup Compliance Policy 后，所有角色都受保护规则约束。项目主人也不能把一份受保护快照丢进垃圾桶，或在快照拍下之后把保留期限改短。Cloud Backup 不能随手关闭，单个集群的备份标准也不能降到项目最低要求以下。MongoDB 的政策文档把这些限制写得很直白，同时提醒客户：删除备份、缩短期限这两条省钱路径会受到限制。

这个设计有它值得付费的地方。企业若想让恢复历史挺过管理员误操作，就得接受管理员有些事情做不了。管理员账号遭人控制时，同一条限制也有了价值。保护能力与管理上的不便，出自同一扇关着的门。

真正尴尬的采购方式，是只让安全团队审批这扇门，把未来的储存费用和人员交接留给别人猜。

项目里多放一个试验，承诺也跟着扩大

这项政策在项目层设定最低标准。文档列出的适用前提是 M10 及以上专用集群；本文讨论 Atlas Core 的这类环境。既有集群会被补齐到项目要求，新增集群也会自动启用相应备份。单个集群可以保留更高要求，项目最低标准只是地板。

因此，把一个短期试验放进哪个项目，也是一项保留期限决策。假设试验服务很快结束，而所在项目要求更长时间保存备份，那么服务的寿命与其历史的寿命从一开始就走上了两条日程。试验负责人可以离开，快照却要按已经接受的规则留下。

改变未来安排也有边界。减少集群备份频率只作用于未来备份，而且仍须满足项目最低要求；已有操作日志保留原本窗口。政策的修改无法靠一次刷新，把所有已受保护的过去变成更便宜的过去。

这让审批的时机变得重要。等到账单会上才问“能不能把旧的删掉”，决策权已经在更早的保护设置中用过了。

集群退役，历史继续占位置

Atlas 的终止流程明确区分了两条路径。启用保护政策时，集群终止后既有快照自动按备份政策保留。没有这项政策、但启用了 Cloud Backup 时，界面提供终止后保留既有快照的选择；Cloud Backup 关闭时则没有这个选项。

保护政策下，Atlas Core 的时间点恢复操作日志还会以静态形式保留，直到无法再用于相应恢复。留下的是已有恢复历史，终止的数据库不会凭空继续产生新业务记录。

因此，退役清单上至少有两个日期：停止运行的日期，以及已有历史各自到期的日期。活跃集群时数有其计费对象，留下的备份储存另有费用。把后者写成“删了集群还在收计算费”，就把问题写错了。

历史也会占住管理结构。政策下只要仍有快照，项目便无法删除；所有项目清不掉，组织也无法删除。MongoDB 还说明，终止后的集群名称被用来识别快照，不能直接用同名新建另一个集群。退役后的储存、标识和管理责任，都需要一个继续存在的收件人。

空名单不等于空项目

政策并非只有打开、永远不能收尾这一种命运。非空项目的停用路径经过指定安全或法律代表：由其提交支持请求，完成验证，获得 MongoDB Support 批准，再由项目所有者停用政策。能管理项目的人，与有资格提出这项请求的人，是两套身份安排。

还有一个写得非常具体的空项目例外：没有活跃集群，没有暂停中的集群，也没有终止集群留下的快照。满足这些条件，组织所有者或项目所有者可以停用政策。

这里最容易发生的误读，是拿一张空的运行中集群列表当作项目已空。列表可以很干净，历史还在。例外的定义把这两件事分开了。

指定代表的邮箱同样属于产品控制的一部分。设置界面要求填写其姓名和用于支持门户的邮箱，错误地址需要通过 Support 修正。一份长期保护政策若只能靠某位前同事的收件箱继续推进，组织就给坚固的技术限制配上了脆弱的人事记忆。现有资料没有具体客户的支持处理时长，无法给这条路径填写一个交付天数。

多存几天，保护未必跟着延长

备份策略文档还描述了额外快照保留：保护期结束后，可以让快照再存一段时间。但进入这段额外期限后，适当角色的用户可以删除它；额外期限结束时，Atlas 自动删除。

这一区别很容易被一张“保留总天数”图表抹掉。存得更久，和在更长时间内禁止删除，是两种购买。公司若需要抵抗拥有删除权限的人，关键日期是保护何时结束；公司若需要随后还能取回历史，额外保留的结束日期又有意义。两个日期都应出现在管理记录里。

策略叠加也有自己的规则。MongoDB 举过一个例子：每日快照留两天，周六的每周快照留三周；如果两项生成同一份快照，它按较长的每周期限保留。三周是这个例子的设置，规则的重点是重叠时采用较长期限。拿较短一栏预测所有快照到期，日历就会失准。

财务模型不能只会数份数

专用集群的备份计费说明又拆掉了一种省事算法：快照份数乘数据库大小。

普通 Cloud Backups 多数情况下采用增量快照，由底层云服务决定增量行为，Atlas 根据服务商报告的储存量与所在区域计费。按 GB 月定义的费用会显示为每日 GB-day 项目，日项本身并非重复收费。Continuous Cloud Backups 则使用自己的费率与快照、内部操作日志合并后的储存量。

部分配置变化、故障切换或底层云维护会导致保留多份完整快照。反过来，一份快照被删掉，别的快照仍引用的数据也会继续存在。份数和费用之间，既不能机械相乘，也不能按同比例相减。具体金额需要客户实际计费储存量、区域、期限和适用费率。

MongoDB 卖出的约束可以很有用：让一家公司的过去不那么容易被一个管理员抹掉。购买时要认真签下的，还有这段过去的账单负责人。保护已经安排好了，责任人总不能还停留在“到时候再说”。