3. 快照策略规划与创建

快照策略是 ONTAP 数据保护体系中最基础、也最容易被低估的一环。很多管理员习惯“先建了再说”，结果卷上堆着几十个命名混乱、保留时间重叠的快照，既占空间又难以判断哪个能用于恢复。真正有效的做法，是先把业务的 RPO（恢复点目标）和 RTO（恢复时间目标）翻译成可执行的调度周期与保留数量，再落到策略对象上。

从 RPO/RTO 推导快照计划

RPO 决定“多久做一次快照”，RTO 决定“恢复时能多快找到并挂回可用副本”。两者共同约束调度周期和保留数量。一个常用的换算关系是：

保留数量 ≈ 覆盖时长 ÷ 调度周期

例如某业务要求 RPO 为 1 小时、需要保留 3 天历史，则至少需要 3×24 = 72 个快照；若 RPO 放宽到 4 小时、保留 7 天，则 7×24÷4 = 42 个。这个数字直接决定策略中的 count 参数，也决定卷上需要预留的空间量。

RTO 则影响策略的“粒度分层”。对于核心数据库，通常采用“小时级 + 天级 + 周级”三层保留：小时级保证最近几小时的快速回滚，天级覆盖误删和逻辑错误，周级用于合规或长期比对。ONTAP 的 cron 调度允许在同一策略中定义多条规则，每条规则独立设置调度表达式和保留数量，这正是分层保留的实现方式。

命名规范：让快照可读、可查、可自动化

ONTAP 默认快照命名格式为 snapshot_name.timestamp，其中 snapshot_name 由策略规则指定。建议采用“业务标识_周期_保留层级”的结构，例如：

• ora_hourly —— 小时级，保留 48 份
• ora_daily —— 天级，保留 14 份
• ora_weekly —— 周级，保留 8 份

这样命名后，通过 volume snapshot show 就能一眼看出快照属于哪个业务、哪个保留层级，也便于后续用脚本按前缀批量清理或审计。避免使用 snap1、test 这类无意义名称，否则在几十个卷的环境中几乎无法维护。

使用 System Manager 创建卷级快照策略

在 System Manager 中，路径为 Protection > Snapshot Policies > Add。界面会要求填写策略名称、作用范围（集群或 SVM）以及至少一条规则。每条规则需要设置：调度类型（如每 8 小时、每天 0 点、每周日）、保留数量、快照名称前缀。System Manager 的优势是可视化校验调度表达式，适合初次规划时快速试算保留份数。

创建完成后，需要把策略应用到目标卷：进入 Storage > Volumes，选中卷，在 Snapshot Policy 下拉中选择刚创建的策略。注意，策略是“卷级”绑定的，同一个 SVM 下不同卷可以使用不同策略，这正是按业务分级保护的基础。

使用 CLI 创建与验证

CLI 更适合批量、可重复的配置。以下示例创建一个名为 ora_protect 的策略，包含小时、天、周三条规则：

volume snapshot policy create -policy ora_protect \
  -enabled true \
  -schedule1 hourly -count1 48 -prefix1 ora_hourly \
  -schedule2 daily  -count2 14 -prefix2 ora_daily \
  -schedule3 weekly -count3 8  -prefix3 ora_weekly

volume snapshot policy add-schedule -policy ora_protect \
  -schedule1 hourly -count1 48 -prefix1 ora_hourly

volume modify -volume ora_data -snapshot-policy ora_protect

创建后应验证三件事：策略是否启用、规则是否按预期解析、卷是否已绑定。可用以下命令检查：

volume snapshot policy show -policy ora_protect
volume snapshot policy show -policy ora_protect -instance
volume show -volume ora_data -fields snapshot-policy

如果 volume snapshot policy show -instance 输出的 schedule 与预期不符，通常是 cron 表达式写错或时区理解偏差。ONTAP 的调度默认使用集群时区，跨时区业务需要特别确认。

策略规划中的常见判断点

第一，保留数量不是越多越好。每个快照都会占用一定元数据和空间，且恢复时需要在列表中定位目标快照，数量过多反而拖慢 RTO。第二，小时级规则不要设置过密（如每 15 分钟）而不评估变更率，否则空间增长会超出预期。第三，策略变更后，已存在的快照不会自动按新规则清理，需要手动删除或等待新规则覆盖。第四，如果卷已启用 SnapMirror 或 SnapVault，快照策略需要与复制策略协同，避免本地保留过短导致复制源被提前删除。

一个可参考的规划示例

假设某企业有 3 类业务：核心 Oracle 数据库、文件共享卷、测试环境卷。按 RPO/RTO 分级后，可形成如下策略规划：

这张表本身就是规划交付物：它把业务语言（RPO/RTO）翻译成了 ONTAP 可执行的参数。创建策略时直接按表填入 -schedule、-count、-prefix 即可，避免现场临时拍脑袋。

最后要强调的是，快照策略不是一次性的配置任务。业务 RPO 会随系统重要性变化，变更率会随数据增长而上升，保留数量需要定期复核。建议每季度用 volume snapshot show -fields policy,create-time 抽查实际快照分布，与规划表比对，及时调整策略，让数据保护始终与业务目标对齐。