快照空间如何被占住
快照本身不复制全部数据，但当源卷改写某个块时，旧数据会被保留在快照一侧，这块空间就一直被占用，直到不再有任何快照引用它。因此同一链上删除不同位置的快照，释放的空间差别很大：链首的快照常被后续快照共享，删掉也回收不了多少；链尾快照独享的旧数据最多，删除后通常释放量最大。清理策略必须建立在这个原理上。
基本信息
| 占用来源 | 源卷改写产生的旧数据、可写快照自身的写入 |
|---|---|
| 回收条件 | 数据块不再被任何快照或卷引用时才真正释放 |
| 策略要素 | 保留层级、老化周期、数量与链深上限、水位触发 |
| 执行代价 | 删除与合并是后台任务，会与业务 IO 争用资源 |
典型使用场景
- 备份策略落地：按小时、按天、按周分层保留，满足不同恢复点
- 空间告急时的应急回收：优先清理无共享关系的链尾快照
- 策略评审：核对快照保留周期是否真的匹配业务恢复点目标
- 批量清理排期：把删除与合并安排在低峰并分批执行
- 遗留环境治理：清理无人认领的历史快照并建立责任人制度
触发条件与建议动作
| 触发条件 | 动作 | 注意点 |
|---|---|---|
| 水位超过警戒值 | 按老化顺序删除链尾快照 | 先评估释放量，避免白跑一趟 |
| 快照数量超上限 | 合并同层级快照并收紧新建权限 | 合并期间避免叠加其他重任务 |
| 最老快照超期 | 按保留策略自动老化 | 确认无合规保留要求 |
| 链深接近上限 | 归并中间层，保持浅链 | 链深与性能相关，不宜长期逼近上限 |
保留策略设计要点
保留策略设计要点
# 层级建议：每小时保留数个，每天保留数个，每周保留数个
# 保留周期与业务的恢复点目标对齐，不做无差别长期保留
# 设两个上限：快照数量上限与快照占用空间上限
# 自动清理优先删最老或链尾快照，并记录清理量与耗时
# 关键变更前手工建一个命名规范的快照，事后单独回收快照不能替代备份：它依赖同一份原始数据，源卷损坏或被误删时快照可能一并失效。快照解决的是短周期恢复，长期保护仍要依赖独立副本。