周四上午，数据平台的会议桌上摆着两张纸。
左边是存储账单。右边是审计发来的意见，只有一句：“历史日志需满足调查和追溯要求，暂不建议删除。”
平台负责人拿着荧光笔，在“暂不建议”下面划了两遍。他问审计：“具体留多久？”
审计说，要看制度。
他又问财务：“希望降到多少？”
财务说，越低越好。
于是三年份的日志夹在两句正确的话中间。删了，怕将来查不到；不删，热存储每月继续扣钱。会议开了四十分钟，最后决定“再评估一下”。
企业里的许多保留策略，就是这样长出来的。它不像策略，更像一段没有结束日期的犹豫。
真正的问题不是审计和成本谁更有道理。两边说的都对，只是各自回答了一个维度。审计在问证据最低要留到什么时候，平台在问数据多快要能取回，业务在问它还有没有用途，财务在问继续保存到底要花多少钱。
把这四件事压成一个“统一保留 3 年”，当然省事。省下来的主要是讨论，代价则由存储、风险和下一任负责人慢慢支付。
文中的容量、期限和费用只用于演示方法，不构成某个行业的法规结论。具体期限必须由法务、合规、审计、安全与数据所有者结合适用规则确认。
先别问留几年：一条期限其实包含 4 个时间点
很多保留表只有一列：retention_days = 1095。
这列看着很干净，却把四种不同决定揉在了一起：
- 热存储截止点：数据还需要秒级或分钟级查询到什么时候；
- 在线或低频截止点：可以接受更慢读取，但仍要直接检索到什么时候；
- 归档截止点：平时不查，遇到调查、争议或重算时仍能恢复到什么时候；
- 最终到期点：没有例外冻结时，什么时候进入验证删除。
同一份安全日志，可能只需要热存 30 天，却要低频保存更久；一份订单操作记录，可能在合同争议窗口内需要较快取回，窗口外只保留经批准的归档；一张可由原始数据稳定重建的聚合表，保存要求又可能短得多。
所以“保留多久”至少要写成一条时间路径，而不是一个孤零零的天数。
维度一：法律、合同与制度，决定不能越过的底线
第一维不是“审计说要留”，而是什么对象，依据什么规则，从哪个事件开始，至少留到哪一天。
这句话里的每个词都要能落到表里。
对象要具体
“日志”不是一种数据。
登录与权限变更记录、订单操作记录、应用调试日志、数据库慢查询、匿名访问统计，包含的信息、对应的风险和调查价值都不同。若一条规则覆盖整个日志桶，往往说明分类还没做完。
至少先写清：
- 数据类别与系统来源；
- 是否包含个人信息、交易信息或敏感业务字段；
- 是否属于安全、财务、合同或行业审计证据；
- 是否存在副本、备份、索引和导出文件。
依据要能引用
保留依据可以来自法律法规、监管规则、客户合同、内部制度、安全调查流程或业务恢复要求。它们不能都写成“合规需要”。
例如，涉及个人信息时，长期保留并不天然更安全。《中华人民共和国个人信息保护法》第十九条规定，除法律、行政法规另有规定外，个人信息的保存期限应当为实现处理目的所必要的最短时间。
这不等于工程师可以自己决定一个最短天数。它意味着团队要同时回答两个问题：为什么必须继续保存，以及目的结束后凭什么还不删除。
起算事件要明确
“保留 3 年”最容易漏掉的是从哪一天开始算。
可能的起算事件包括：
- 记录生成；
- 账号注销；
- 合同终止；
- 订单结案；
- 审计年度结束；
- 安全事件关闭。
如果起算事件没有字段，规则就无法自动执行。系统只知道对象创建日期，组织却以合同终止日期为准，两者之间会差出一大截。
例外冻结要独立
调查、诉讼、争议或事故处理中，某批数据可能要暂停自动删除。这个例外不能靠人在群里喊一句“先别删”。
保留表至少要有冻结范围、原因、发起人、批准人、开始时间、复核时间和解除条件。冻结解除后，数据也不应直接消失，而要重新计算到期日并走一次审批。
第一维的产物不是一个年限，而是一条可引用、可起算、可暂停、可复核的底线。
维度二：恢复与调查时效，决定数据放在哪一层
满足保留要求，不等于把所有数据一直放在最快的存储层。
真正决定冷热分层的，是什么时候会用、需要多快拿到、拿到后能不能读。
可以把需求拆成三类：
| 使用场景 | 典型问题 | 需要写清的服务目标 |
|---|---|---|
| 日常排障 | 最近几小时发生了什么 | 查询延迟、可用时间窗 |
| 事故与审计 | 某个账号在某日做了什么 | 取回时限、检索范围、访问审批 |
| 历史重算 | 原始记录能否重放出明细 | 恢复时间、解析版本、校验方式 |
