摘要

  • 支持软删除的 Google Cloud Storage 存储桶，默认保留期为七天。对象从活跃列表消失后，软删除对象仍在产生存储费。
  • 新策略生效前已经软删除的对象，继续遵守删除时的原保留期。事后关闭功能，只能改变后续流入，不能提前清空旧库存。

清理任务把回收站养肥了

每天删临时文件，听起来像一条省钱纪律。在 Google Cloud Storage，清理任务也可能是一台给另一座仓库进货的机器。

原因写在官方文档里。软删除将被删除或覆盖的对象保留一段时间，供误删或恶意删除后恢复；在保留期内，它们继续收存储费。支持该功能的存储桶，默认窗口是七天。对象已经退出日常工作，账单上的住宿登记还没退。

这个功能有明确价值：它让一次错误删除不必立刻变成无法挽回的损失。但它买的是恢复机会，成本取决于多少数据在这个机会里待多久。只盯着还在用的容量，会漏掉正在等待反悔的数据。

活跃一份，身后可能排着七份

把条件说清楚，算术就很直接。假设全部内容都在同一地区的 Standard 存储类别，关闭对象版本控制，没有额外恢复出来的副本。活跃内容始终为 1 TiB；工作负载持续、均匀地每天删除 1 TiB，并已运行至少七天。软删除窗口保持七天。

达到稳定状态后，删除流量每天 1 TiB 乘以七天，形成约 7 TiB 的软删除内容。加上活跃的 1 TiB，约有 8 TiB 内容处在持续产生存储费的状态。业务没有保留更多正在使用的数据，删除吞吐量却替它积出了一层收费库存。

这是一组给定条件下的容量计算。实际金额还需存储桶的删除速率、对象类别、地区和合同单价；请求、网络、折扣等项目另算。不能拿这 8 TiB 去宣布整张云账单涨了八倍。

Google 的价格页明确说，活跃对象、非当前版本和软删除对象，按同样方式计算存储费。不同的是对象所处状态，持续占用的字节时间仍然计价。

今天关闭，昨天的预约还有效

保留期可以设为七至九十天，也可以关闭软删除；新桶的默认策略同样可以调整。这里最容易买错的，是调整发生的时间。

官方规则只让新策略影响生效后被删除的资源。已经软删除的对象，继续按照删除当时的期限保留。例如第零天按七天策略删除，第一天改主意、关闭策略，那个对象仍走原来七天的日程。关闭按钮不会把既有副本提前送走。

因此，停止未来流入和清空既有库存，是两件不同的事。旧批次会各按到期时间退出。最新的一批，可能还要等上接近原保留期的时长。财务若把“已关闭”理解成“明天费用归零”，就会把一个时间表误当成一个开关。

生命周期到站，账期还会换乘

自动生命周期规则也不是这段等待的捷径。规则删除的对象可以进入软删除状态；已经软删除的对象，不能再靠生命周期规则提前永久删除或改换存储类别。若开启对象版本控制，删除活跃对象还可能先变成非当前版本，所以前面的计算特意排除了这一层。

Google 自己点名了容易被这笔账绊住的工作：短命临时对象、查询结果、中转文件，以及删除频繁的负载。这些数据可能几分钟就能重新生成，却在每次丢弃后买下一周恢复时间。

选择恢复窗口，应该比较数据丢失的代价与重新生成的成本。无法重建的原始数据值得认真保护；可随时重跑的中间产物，应有自己的经济账。把两者塞进同一个默认策略，只是省掉了一次决策，未必省掉了费用。

临时文件退出工作，不等于退出计费。清理动作越勤快，越要知道它把东西送到了哪里。回收站可以是救命绳，也可以是最守时的收租人。

来源