每周生成一份备份，旧的那份随手删掉，流程很自然。可如果你同时选了Google Cloud Storage的冷存储层，保留期限就需要重新对一遍。我会先算“这份文件实际留下几天”，再比较容量单价。
一个简单的起点是：近期轮换的备份和准备留一年的资料分别安排。它们都叫备份，却不必承担同样的存储条件。
七天轮换，先别只看最低单价
Standard没有对应的最低存储期；Nearline为30天，Coldline为90天，Archive为365天。[1] 这并非不允许提前删除，而是提前删除、替换或手动移动对象时，需要按规则计入最低期相关费用。
| 你的轮换计划 | 值得先比较的方向 | 额外核对 |
|---|---|---|
| 每周替换一份近期备份 | Standard完整成本 | 读取频率与保护保留 |
| 稳定保存数月，偶尔恢复 | Nearline / Coldline | 最低期与取回费用 |
| 长期留一年以上的资料 | Archive等长期选择 | 完整读取与传输估算 |
假设普通Nearline对象在第7天永久删除，且没有改变适用规则的特殊条件，估算就不能只算7天的容量费。若需要随时拿最近的数据恢复，先为这种灵活性留预算，我觉得比事后解释提前删除费更省事。
自动转层有例外，别把规则说成一刀切
官方对Object Lifecycle Management改变存储类别和启用Autoclass的桶列出了提前删除费用例外。[1] 因此，手动转层、生命周期转层与自动分类，不应被写成完全相同的一种操作。
如果准备靠规则长期管理文件，我会先画一条时间线：上传、可能读取、转层、最后清理分别在什么时候。再按选定机制核对操作和管理费用。自动化减少了日常操作，不代表所有费用也一起消失。
删了当前文件，空间为什么还没降
价格页明确说明，当前对象、非当前版本和软删除对象都计入存储费用。[1] 如果你保留旧版本或开启软删除，恢复保护会占用空间。这未必是坏事，只是预算要容得下它。
我会先给不同资料定保留理由。容易重建的中间文件不需要跟重要原始数据保留一样久；保护期也应配合你通常多久发现误删。先作这个区分，比看到容量上涨就急着关闭保护更稳妥。
数据拿到哪里，也影响这笔钱
同一地区内的适用数据传输，与跨位置读取需要分别判断；一个区域即使位于某个多区域的地理覆盖内，也不自动被视为同一位置。[1] 所以，程序在哪里跑、桶具体在哪里，值得写进估算条件。
近期每周轮换，先比较Standard完整成本；准备保留数月或一年，再按实际期限比较冷存储。生命周期转层与Autoclass有各自例外，不能套手动操作的同一笔费用。估算同时数清旧版本、软删除与恢复目的地，这些才是容易从容量单价里漏掉的部分。
资料核对与适用范围
本轮核对所列可读官方价格与生命周期文档，按临时部署、备份恢复和数据库维护作资料选购评估。算术为明确假设；编辑建议不代表本站租机、存储读写、故障演练或扣费体验。
地区、系统许可、账户类型、部署方式、资源保留与适用计费条件需按实际账户核对。本站未登录商家、租机、上传对象、创建数据库、恢复备份或付费调用；本文不能证明实际性能、恢复时间或最终账单。