两层快照各自解决什么
虚拟机快照由虚拟化平台管理：它对虚拟磁盘打点的同时可以保存内存与设备状态，因而能回退到运行中的精确瞬间，但受磁盘格式与平台能力限制，容量与数量都有上限。存储快照由后端阵列完成：以卷为单位打点，对主机透明、容量效率高、便于复制到远端，却完全感知不到虚拟机与文件系统层面的状态。两者协同的核心，是让两层的打点落在同一个可恢复点上，而不是各自独立生成。
关键概念
| 虚拟机快照 | 平台侧打点，可包含内存与设备状态，回退粒度细 |
|---|---|
| 存储快照 | 阵列侧打点，主机透明，容量效率高且可远程复制 |
| 协同目标 | 让两层打点落在同一可恢复时间点 |
| 常见机制 | 平台通过接口触发存储快照，或在静默窗口内先后打点 |
| 关键约束 | 打点期间需暂停或静默写入，避免跨层不一致 |
| 容量特征 | 虚拟机快照增长快，存储快照更适合长期保留 |
典型使用场景
- 系统升级或补丁批量变更前，建立可快速回退的恢复点
- 容灾演练中需要同时回退虚拟机状态与后端卷数据
- 虚拟机数量多、单机快照不可控时，转由存储侧承担保留职责
- 需要把恢复点复制到远端站点，用于站点级故障恢复
- 排查快照空间被快速消耗的问题，判断增长来自哪一层
- 评估虚拟化平台与存储阵列的集成能力是否满足自动化要求
协同方式对比
| 协同方式 | 机制 | 优点 | 局限 |
|---|---|---|---|
| 平台触发存储快照 | 平台调用存储接口对卷打点 | 控制点单一，时间点一致 | 依赖平台与阵列的集成能力 |
| 存储后再平台打点 | 先由阵列打点，再由平台记录状态 | 不依赖集成接口 | 两次打点之间仍存在时间窗口 |
| 静默加双层打点 | 先静默应用，再连续打点两层 | 一致性与可恢复性最好 | 需要业务配合，静默窗口有限 |
| 平台快照加远程复制 | 平台本地打点，再由存储复制到远端 | 实现简单，改动小 | 快照数量受限，长期保留成本高 |
| 仅存储快照加应用恢复 | 阵列打点，靠应用日志恢复 | 容量效率高，可长期保留 | 要求应用支持从崩溃一致状态恢复 |
协同打点流程
协同打点流程
# 第一步：确认业务可静默，或选择低写入窗口作为打点时机
# 第二步：执行应用层静默——刷盘并暂停写入，避免跨层不一致
# 第三步：发起存储快照，得到卷级一致的可恢复点
# 第四步：在同一静默窗口内记录虚拟机状态或元数据，避免两次打点错位
# 第五步：解除静默并恢复写入，检查业务状态与队列是否出现积压
# 第六步：按需把存储快照复制到远端，用于站点级故障恢复两层快照的容量特征差异很大。虚拟机快照在写入持续进行时增长率很高，通常只适合升级、变更这类短窗口使用；存储快照基于打点差异，占用空间与变化量相关，更适合承担长期保留与远程复制。把长期保留放在虚拟机快照上，常见后果是数据存储在几天内被写满，进而影响所有虚拟机。