保留和保留策略

1）原则

1.Purpose & Minimization.我们存储的正好和处理目标所需的正好一样多。
2.Policy as Code.重新定义是可执行的策略而不是PDF。
3.Defense in Depth.TTL/ILM+加密+审计+法律保留。
4.Reversibility & Proof.删除是可验证的：动作日志、加密切片、合规报告。
5.Cost & Carbon Aware.还原考虑了$/GB 月份和碳存储足迹/egress。

2）数据分类和"重新映射"

• 运营（OLTP）：订单，付款，会话。
• 分析（DWH/日期）：事件，日志事实，切片。
• 个人（PII/财务/健康）：需要特殊的时间表和实体的权利。
• 技术：徽标，度量，步道，CI工件。
• 文件/媒体：WORM/存档/legasi。

对于每个班级，设置为：所有者，目标，法律框架，时限，保护级别，当前和目标存储。

3） ILM： 数据生命周期

1.Ingest（热门）→ NVMe/SSD,高请求频率。

2.Warm →不太可能读取，压缩和柱形格式。

3.Cold/Archive →对象/磁带,长期访问。

4.Purge/Delete →保证删除（副本/备份）。

yaml dataset: events_main owner: analytics purpose: "product analytics"
classification: "pseudonymized"
lifecycle:
- phase: hot; duration: 7d; storage: nvme; format: row
- phase: warm; duration: 90d; storage: ssd; format: parquet; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d privacy:
pii: false dp_delete_window: 30d # SLA on personal deletions if ligaments appear

4）策略作为代码（有用的素描）

4.1 Admission Policy （强制性标签/TTL）

yaml policy: require-retention-tags deny_if_missing: [owner, purpose, classification, retention]
default_retention:
logs:  "30d"
traces: "7d"
metrics:"90d"

4.2 Gate in CI/CD （Rego）-禁止在没有重建的情况下进行降级

rego package policy. retention deny[msg] {
some d input. datasets[d].retention == ""
msg:= sprintf("Retention missing for dataset %s", [d])
}

4.3 S3/对象（lifecycle片段）

yaml
Rules:
- ID: logs-ttl
Filter: { Prefix: "logs/" }
Transitions:
- { Days: 7, StorageClass: STANDARD_IA }
- { Days: 30, StorageClass: GLACIER }
Expiration: { Days: 180 }
NoncurrentVersionExpiration: { NoncurrentDays: 30 }

5）在线程和队列中保留

Kafka:

`retention.ms`/`retention.bytes'是窗口重建。
Compaction (`cleanup.policy=compact"）-存储密钥的最后一个值。
Tiered Storage-将"尾巴"带入冷射击场。
DLQ是单独的还原和TTL。

properties cleanup. policy=delete,compact retention. ms = 604800000 # 7d for tail removal
min. cleanable. dirty. ratio=0. 5 segment. ms=86400000

• 在业务恢复/重新计算窗口≈定义关键拓扑的重构。
• 对于事件，计费/审计-单独的长续集或WORM。

6）数据库和重建

• 按日期/范围分组，detach和drop旧分组。
• 日期字段是TTL查询的索引。
• 较旧版本的节奏表（系统版本）+polysi purge。

sql
-- Monthly instalments
CREATE TABLE audit_events (id bigserial, occurred_at timestamptz, payload jsonb) PARTITION BY RANGE (occurred_at);
-- Cleaning over 365 days
DELETE FROM audit_events WHERE occurred_at < now() - interval '365 days';
VACUUM (FULL, ANALYZE) audit_events;

NoSQL/Time-series:

关键级TTL（MongoDB TTL索引，Redis "EXPIRE"，Cassandra TTL）。
用于度量的Downsampling（原始7d → aggregat 90 d →长365 d）。
TSDB中的Retention Policy（带有滞后/聚合功能的Influx/ClickHouse材料化视图）。

7） Logi, Metrics, Tracks

Logs：限制字段,掩盖PD, TTL 7-30d, archive 90-180 d。

度量： 原始高频为7-14 d；downsample (5m/1h) — 90–365д.

Traces： tail-sampling和存储"有趣"（错误/尾巴）更长。

yaml observability:
logs:  { ttl: "30d", archive: "90d", pii_mask: true }
metrics: { raw: "14d", rollup_5m: "90d", rollup_1h: "365d" }
traces: { sample: "tail-10%", ttl: "7d", error_ttl: "30d" }

8）删除： 类型和保证

逻辑（软删除）：记录标记；方便恢复，不符合"处置权"。
物理（hard-delete）：实际删除数据/版本/复制副本。
加密（crypto-erasure）：删除/替换加密密钥,之后数据无法恢复。
级联：端到端去除推导（腰果，索引，分析）。

request → locate subject data (index by subject_id) → revoke tokens & unsubscribe jobs → delete in OLTP → purge caches → enqueue erasure in DWH/lakes → crypto-shred keys (per-tenant/per-dataset) → emit audit proof (receipt)

9）删除权，法律保留和eDiscovery

删除/更正权：执行SLA（例如≤30天），跟踪动作，收据。
法律保留：在法律要求下,冻结指定集/密钥的删除；优先于TTL的政策。
eDiscovery：数据目录,全文/归因文物搜索,以一致的格式导出。

yaml legal_hold:
dataset: payments scope: ["txn_id:123", "user:42"]
from: "2025-10-31"
until: "2026-03-31"
reason: "regulatory investigation"

10）Bacaps vs Archives vs WORM

Backaps-从损失/损坏中恢复；短续集，快速RTO。
存档是用于审计/分析的长期存储，价格便宜，访问时间长。
WORM-不变的合规媒体（财务/报告）；"write-once, read-many"策略。

• 不要指望备用是"世纪档案"。
• 恢复排练（DR天），时间和完整性报告。
• 带有还原、加密和密钥的备份目录与存储区分开。

11）私有化和匿名

别名化：通过密钥表延迟绑定PII（允许按密钥进行加密擦除）。
匿名：不可逆转的技术（k匿名，噪音，概括）；记录方法、重新识别风险和保质期。

12）合规监测和报告

控制面板：具有有效还原的dataset的比例,ILM相位的体积,删除错误。
Alerts：在热破折号中超过目标音量,"失速"删除,到期的Legal Hold。
报告：每月删除审计（请求数量，平均期限，失败），加密抢购打印。

13）集成到流程中： 门和咆哮

设计门：新的dataset不经过咆哮没有"主人/purpose/retention"。
释放门：在没有所有者/理由的情况下增加重建的迁移-被阻止。
成本门：热量/热量超过预算-触发ILM收紧。
安全门：禁止在不伪装和TTL的情况下将PD包含在逻辑/跟踪中。

14）反模式

"我们永远保持一切-突然会有用。"

未在策略中指定的应用程序中硬编码的TTL。
无伪装/TTL/删除日志和跟踪中的 PD。
删除不完整（保留在缓存/DWH/备用中）。
缺少Legal Hold-正在调查的数据擦除。
单个通用加密密钥都是不可能的"加密擦除"。
零观察力："我们相信他们已经删除"，但没有证据。

15）建筑师支票清单

1.对于每个Dataset,是否都有所有者、购买者、分类者、保留者、存储层级?

2.ILM/TTL策略被声明为代码并自动应用?

3.PD伪装成日志/预告片；是否禁止在"白色"套装之外使用？

4.有个人删除程序（SLA,审计,收据）?

5.Crypto-erasure是可能的（per-tenant/per-dataset keys, KMS/rotation）?

6.备用： 时间表,加密,恢复测试,单个密钥?

7.Legal Hold/eDiscovery： 支持,优越TTL,维护活动日志?

8.Kafka/队列： 设置为还原/compaction/tiering, DLQ有不同的策略吗?

9.重构合规性指标和Alerta以及按长篇大论调整的卷?

10.SDLC中的Review和Gate是否会阻止没有重建的文物？

16）迷你食谱

16.1 ClickHouse："切断尾巴"超过180天

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16.2 Redis: TTL и lazy-purge

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16.3 Tail-sampling for Trail

yaml tail_sampling:
policies:
- name: keep-errors-and-slow latency_threshold_ms: 500 status_codes: ["5xx"]
rate_limit_per_min: 5000 default_ttl: "7d"

16.4 Crypto-erasure（想法）

keys:
dataset: users_pii key_id: kms://pii/users/tenant-42 erase(user_id=42):
rotate_or_destroy (key_id) # inability to restore former purge_indexes blocks ("user _ id = 42")
audit("crypto-erasure", user_id)

结论

存储策略是您的数据平台的"骨架"：它们描述了不同数据类别的生活，它们在每个时刻的位置，随着时间的推移变得多便宜，以及何时消失而没有痕迹-合法，透明和可验证。将重新定义为代码，将ILM连接到安全和成本，启用可观察性和网关-并且您将获得一个既有效，又可兼容且可以增长的系统。