1. 数据保留策略概述
数据保留策略，说白了就是回答三个问题：数据存多久、存在哪、怎么删。我做了十几年数据架构，见过太多公司要么把所有数据堆在一起不舍得删，要么为了省存储空间一刀切全清掉——这两种做法都容易出事。
今天咱们先聊聊为什么需要这东西，再讲清楚两个核心概念 RPO 和 RTO，最后看看策略本身怎么管、怎么迭代。
1.1 为什么需要数据保留策略
你可能觉得，数据保留不就是设个定时删除任务吗？其实没那么简单。我遇到过一家金融客户，因为没定义清楚交易日志的保留周期，被审计罚了 200 万。你想想看，这钱花得多冤。
归纳下来，数据保留策略的必要性体现在四个方面：
- 合规要求：GDPR、等保 2.0、金融行业监管规定……不同行业、不同地区对数据保存期限有硬性要求。不遵守就是罚款，甚至吃官司。
- 成本控制：存储不是免费的。热数据、温数据、冷数据，每 GB 的成本差好几倍。我见过一家公司把 3 年前的监控视频存在 SSD 上，一年白花 50 万。
- 性能保障：数据量越大，查询越慢。保留无用的历史数据，等于给数据库背上一个越来越重的包袱。
- 风险管控：数据越多，泄露风险越大。保留不必要的数据，就是在给自己埋雷。
核心观点：数据保留不是「能省就省」，而是「该留的留，该删的删」。留错了是成本，删错了是事故。
1.2 核心概念：RPO 与 RTO
聊数据保留，绕不开两个指标：RPO 和 RTO。这两个词在灾备领域经常出现，但很多人把它们搞混了。我简单解释一下。
| 概念 | 全称 | 通俗理解 | 典型值 |
|---|---|---|---|
| RPO | Recovery Point Objective | 你能容忍丢多少数据？ | 金融核心系统：0~5 分钟；一般业务：1 小时~1 天 |
| RTO | Recovery Time Objective | 你能容忍停多久？ | 金融核心系统：< 15 分钟；一般业务：4~24 小时 |
举个例子你就明白了。假设你运营一个电商平台，凌晨 2 点数据库挂了。
- 如果 RPO 是 1 小时，意味着你可以接受丢失凌晨 1 点到 2 点之间的订单数据。
- 如果 RTO 是 4 小时，意味着你必须在早上 6 点前恢复服务。
这两个指标直接决定了你的备份频率、备份方式、存储层级。RPO 越短，备份越频繁，成本越高。RTO 越短，恢复手段越复杂，投入越大。
我的经验：别一上来就追求 RPO=0、RTO=0。那不现实。先问业务方：「你能接受丢多少？能等多久？」拿到答案再定技术方案。
1.3 策略的生命周期管理
数据保留策略不是写一份文档就完事了。它跟软件一样，有生命周期。我个人习惯把它分成五个阶段：
- 定义阶段：明确数据分类、保留期限、存储层级、删除规则。这个阶段要拉上法务、业务、运维一起讨论。
- 实施阶段：把策略落地到技术工具上。比如配置备份策略、设置生命周期规则、部署归档任务。
- 监控阶段：定期检查策略是否被执行。我见过不少公司配置了规则，但从来没验证过——结果数据该删的没删，该留的丢了。
- 审计阶段：配合内部或外部审计，证明你的策略是有效的。审计最怕的就是「你说你做了，但拿不出证据」。
- 优化阶段：业务变了、法规变了、技术变了，策略也得跟着变。每年至少 review 一次。
下面这张图可以帮你直观理解这个生命周期：
注意：我曾经见过一个团队，策略定义得很漂亮，但实施时发现备份系统不支持按标签自动删除。结果策略成了摆设。所以，定义阶段一定要确认技术可行性，别写「空中楼阁」式的策略。
嗯，到这里你应该对数据保留策略有了一个整体的认识。简单总结一下：
- 为什么要做？合规、成本、性能、风险，四个维度缺一不可。
- 核心指标是什么？RPO 决定你丢多少，RTO 决定你等多久。
- 策略怎么管？定义→实施→监控→审计→优化，循环迭代。