4. 快照策略规划

快照策略规划的本质，是把业务对“数据能丢多少、多久能恢复”的要求，翻译成 HPE Alletra 上可执行的快照频率、保留数量、一致性组划分和资源开销预算。策略定得太松，RPO 无法满足；定得太紧，快照元数据、容量占用和阵列负载又会反噬生产性能。因此规划的核心不是“多打快照”，而是找到业务可接受风险与存储系统可承受开销之间的平衡点。

一、从 RPO/RTO 推导快照频率

RPO（Recovery Point Objective）决定“两次快照之间最多允许丢多少数据”，它直接约束快照间隔；RTO（Recovery Time Objective）决定“从故障发生到业务恢复可用”的时间上限，它约束的是恢复方式与流程，而不是快照频率本身。两者必须分开分析，否则容易把“多打快照”误当成“恢复更快”。

快照频率的推导公式很直接：快照间隔 ≤ RPO。若某业务 RPO 为 15 分钟，则快照间隔必须不大于 15 分钟；若 RPO 为 4 小时，则每小时一次已足够。但实际规划还要叠加两个修正因素：一是快照创建本身需要时间，间隔必须大于单次快照完成时间；二是应用写入的突发性，若业务存在集中批量写入窗口，应在窗口前额外增加一次快照，而不是机械地按固定间隔平均分布。

以一个教学示例说明：某订单库 RPO 要求 30 分钟、RTO 要求 2 小时。按 RPO 推导，快照间隔取 30 分钟即可满足；但订单系统在每日 10:00 和 20:00 有两次批量对账写入，若快照恰好落在批量写入中途，恢复点会包含不完整批次。因此实际策略调整为：常规每 30 分钟一次，并在 09:55 和 19:55 各增加一次“批次前快照”。这样既满足 RPO，又保证恢复点落在业务一致的位置。

二、保留策略：数量、时长与容量三者联动

保留策略要同时回答三个问题：保留多少个恢复点、保留多长时间、占用多少容量。HPE Alletra 的快照采用写时重定向机制，快照本身初始几乎不占容量，但源卷数据被改写时，旧数据块会被保留，容量随“改写量 × 保留时长”增长。因此保留策略不能只看数量，必须估算容量。

一个可用的估算方法是：快照容量 ≈ 源卷日改写量 × 保留天数 × 冗余系数。例如源卷 2 TB，日均改写率 8%，保留 7 天，冗余系数取 1.2，则快照容量约为 2 TB × 8% × 7 × 1.2 ≈ 1.34 TB。若阵列剩余容量不足以支撑该值，就必须缩短保留时长或降低频率，而不是等到容量告警再被动清理。

保留策略通常采用“分层保留”而非单一规则：近期保留密、远期保留疏。例如每 30 分钟一次保留 24 小时（48 个点），每小时一次保留 7 天（168 个点），每日一次保留 30 天（30 个点）。这样既能满足短期精细恢复，又能覆盖长期合规或误删回溯需求，同时避免保留点数量无限膨胀。

三、一致性组：保证多卷恢复点的业务一致性

当业务跨越多个卷（如数据库的数据卷、日志卷、归档卷）时，若各卷独立打快照，恢复点时间会错位，可能导致数据库无法启动或数据逻辑不一致。一致性组的作用，就是把需要同时恢复的多个卷绑定为一组，在同一时间点统一创建快照，保证组内所有卷的恢复点严格对齐。

一致性组的划分原则是“按业务恢复单元划分”，而不是按卷数量平均划分。一个数据库实例的数据卷、日志卷、临时卷应放入同一组；不同数据库实例之间若互不依赖，可各自成组。组内卷越多，单次快照的协调开销越大，因此不建议把几十个无关联卷塞进同一组。

一致性组还需要考虑应用层配合。对于有缓存或事务日志的应用，仅靠存储层一致性组只能保证“卷级时间点一致”，不能保证“应用事务一致”。此时应结合应用静默（如数据库的冻结/解冻脚本）或日志回放机制，在快照前让应用进入可恢复状态。HPE Alletra 的快照可与编排工具联动，在快照前后触发应用脚本，形成“应用一致快照”。

四、业务影响评估：快照不是零成本操作

快照创建本身对生产 I/O 的影响通常很小，但以下三类开销必须评估：第一，快照元数据写入和指针更新会占用少量控制器资源，高频快照（如每分钟一次）在大量卷上叠加时可能形成可观负载；第二，快照保留导致的容量增长会改变阵列容量水位，进而影响写性能和告警阈值；第三，恢复操作（尤其是挂载快照卷供主机读取）会引入额外读 I/O，若在业务高峰执行，可能拖慢生产。

因此规划时应明确“快照窗口”和“恢复窗口”。快照创建尽量避开业务峰值，恢复演练或实际恢复尽量安排在低峰期。对于关键业务，建议先在测试卷上验证快照频率与保留策略的实际容量增长曲线，再推广到生产卷。

五、把策略落到可执行的规划表

完成上述分析后，建议把每个业务卷或一致性组的策略整理成一张规划表，字段至少包含：业务名称、卷/一致性组、RPO、RTO、快照间隔、保留分层、预估快照容量、快照窗口、恢复窗口、验证方式。下面给出一个可直接参考的示例结构（参数为教学示例，非实测值）：

规划完成后，必须通过一次恢复演练来验证 RTO 是否可达。演练时记录从发起恢复到业务可用的实际耗时，若明显超过 RTO，应优先优化恢复流程（如预挂载、并行恢复、脚本自动化），而不是继续加密快照频率。快照频率解决的是“能恢复到多近”，恢复流程解决的是“多快能恢复”，两者不可互相替代。

最后，快照策略不是一次设定后永久不变的。业务写入模式、数据增长速度和合规要求都会变化，建议每季度复核一次容量增长曲线与恢复演练结果，按实际数据回调快照间隔和保留层数，使策略始终与业务风险和阵列容量保持匹配。