Lakehouse 快照保留与恢复演练：引用水位、文件回收和 Legal Hold

数据团队看到对象存储增长，便执行 expire snapshots 和 remove orphan files。SQL 成功、空间下降，却在次日才发现训练任务仍引用昨天的 snapshot ID，审计导出还需要一个月前的 manifest，长写任务产生的文件因“看起来未被引用”被孤儿清理。快照表的原子提交只保护一次元数据切换，不替团队决定哪些历史仍有活跃读者。

Apache Iceberg 以 snapshot、manifest list、manifest 和 data/delete file 组成表状态，维护过程可以过期历史 snapshot、清理旧 metadata 和孤儿文件。危险点在于回收是不可逆副作用：一个迟到 reader、未登记 branch 或仍运行的 writer，都可能让“未被当前表引用”成为错误结论。训练数据集快照定义数据集血缘，RAG 签名索引制品保护派生索引；本篇治理底层表文件何时才可删除。

retention policy 必须看见所有引用

发布 lakehouseRetentionPolicy.v1，绑定 table UUID、format/spec 版本、catalog、受保护 branch/tag、最短 snapshot 年龄、reader lease 上限、writer 最大时长、灾备点、legal hold generation、对象版本策略和回收实现 digest。每个训练、回填、导出或审计任务在开始前登记 snapshotLease，包含 snapshot ID、purpose、owner、expiresAt 和 reader generation；未知 reader 禁止依赖“以后还能 time travel”。

schema: lakehouseRetentionPolicy.v1
table: orders/7f31...
protectedRefs: [main, audit-q2]
minSnapshotAge: 30d
maxReaderLease: 14d
maxWriterDuration: 6h
legalHoldGeneration: 19
orphanSafetyInterval: 12h

候选回收集合只能从固定 catalog generation 计算。live refs、未过期 reader lease、进行中 writer 的 staging prefix、灾备 checkpoint 和 hold scope 求并集后，才得到不可删除闭包。orphanSafetyInterval 必须大于最长 writer 可见延迟并有实测依据；仅靠文件 mtime 会把慢上传、跨区复制或时钟漂移误判。删除请求携带 candidate manifest root，而不是后台重新枚举后扩大范围。

删除分成可撤销标记与不可逆清除

状态先分叉：命中 live ref、有效 lease、writer、灾备点或 hold 的对象进入 PROTECTED 并退出候选；只有 DISCOVERED -> UNREFERENCED_ELIGIBLE -> QUARANTINED -> RESTORE_VERIFIED -> DELETE_APPROVED -> DELETED -> VERIFIED 可以继续。过期 snapshot 从新 reader 的默认历史移出前，必须创建仅供隔离恢复的 quarantine/<candidateId> tag，或封存足以独立 bootstrap 的签名 metadata bundle、ref root 与所有对象 version ID；该临时 tag 固定文件但不改变其已通过的 eligibility 证据，隔离期内 hold 或新外部引用仍会把候选退回 PROTECTED。

唯一不可逆接受点是 deleter CAS 比较 table generation、protected-ref root、lease watermark、hold generation 和已验证 quarantine tag/bundle root 后，封存精确对象清单、移除临时 tag 并提交给存储层。任一值变化都退回重新计算。不能先运行会移除最后一条 snapshot 元数据链的 expiration，再假设尚未物理删除的数据文件足以恢复表。

对象删除回执记录 version ID、etag/digest、请求和确认时间、provider result；多版本 bucket 还要说明删除 marker 与旧 version 的处置。元数据 JSON 可读不等于数据完整，恢复器应从 quarantine tag 或独立 bundle 的 catalog bootstrap 开始，递归验证 snapshot、manifest 和 data/delete file 摘要。训练分片原子发布提供集合完整性思路，数据库迁移则提醒旧 reader 与新格式要有兼容窗口。

每次回收前先证明可恢复

故障矩阵注入 reader 登记后控制面延迟、branch 名大小写混淆、writer 上传后未提交、对象列表最终一致、hold 与 delete CAS 同时发生、受保护 snapshot 误入候选、默认 ref 移除后 metadata bundle 缺一层、snapshot 已过期但模型仍引用、跨区副本滞后、删除回执丢失和 version marker 恢复。预期是延后回收或明确 DELETE_UNKNOWN，不能用当前查询成功代替历史恢复。

门禁可要求：受保护 ref 和有效 lease 中被删除对象为 0；candidate manifest 与实际删除集合差异为 0；每周从隔离区随机恢复 30 个 snapshot 全部通过 root 校验；每季度从冷备完整恢复关键表 RTO 小于 4 小时、RPO 等于声明 checkpoint；hold 生效后新删除接受为 0；UNKNOWN 删除 100% 进入对账。存储节省不能抵消一次不可恢复。

发布先只生成 candidate 报告并与现有维护任务比较两周，再让新策略处理一个无合规数据的测试表，之后按 table cohort 扩大。异常时停止不可逆 deleter，从受保护 tag 或已验证 bundle 恢复默认 ref 并延长隔离期；已经删除的对象只能从有证明的副本恢复，不能伪造原 snapshot。训练数据删除传播要求该删的数据最终消失，legal hold 与删除权利的冲突由获授权治理层决定，维护程序只执行版本化决定。