云快照一致性是什么
云平台默认卷快照给到的是崩溃一致视图：等价于在那一瞬间拔掉电源，文件系统元数据基本完好，但应用内存里没落盘的写入会丢。数据库、消息队列这类有内存缓冲的服务，或者数据卷与日志卷分开的多卷部署，都需要额外的冻结或停写动作，才能拿到应用一致副本。
基本信息
| 适用平台 | AWS EBS 快照、阿里云 ECS 快照、腾讯云 CBS 快照等；机制相近 |
|---|---|
| 崩溃一致性 | 无需应用配合，恢复后需走应用自身的崩溃恢复流程 |
| 应用一致性 | 需先让应用停写或进入静默（冻结文件系统、数据库锁、备份模式），再打快照 |
| 多卷场景 | 用平台的一致性组能力，或在同一冻结窗口内逐卷打点 |
典型使用场景
- 静态文件与镜像目录：崩溃一致已经足够，抓一个时间点即可
- 单库单卷部署：先执行数据库检查点或锁表，再触发卷快照
- 数据库数据与日志分卷：必须用一致性组或同一冻结窗口，避免时间点错位
- Windows 业务机：借助 VSS 让应用进入静默后再快照
- 跨区复制前的本地兜底：本地快照确认可用后再复制到异地
冻结窗口内打快照（Linux）
冻结窗口内打快照（Linux）
# 1) 冻结文件系统：新写入挂起，等待快照完成
fsfreeze -f /data
# 2) 在冻结窗口内调用云 API 创建快照（应为秒级完成）
# aws ec2 create-snapshot --volume-id vol-xxxxxxxx --description "app-data"
# 3) 快照请求返回后立即解冻，恢复业务写入
fsfreeze -u /data
# 4) 确认已解冻，写挂起状态不应残留
mount | grep -w frozen
# 多卷场景：同一窗口内对数据卷与日志卷分别触发，或用一致性组能力
# aws ec2 create-snapshots --instance-specification InstanceId=i-xxxxxxxx两类一致性对照
| 类型 | 快照时点状态 | 恢复后要做的事 |
|---|---|---|
| 崩溃一致 | 内存数据丢失，文件系统可挂载 | 起库时执行应用自身的崩溃恢复 |
| 应用一致 | 事务边界上的完整状态 | 多数场景可直接启动，无需长恢复 |
| 多卷一致性组 | 各卷落在同一点，卷间关系不乱 | 确认挂载顺序与设备映射后启动 |
| 分别打快照 | 各卷时间点彼此错开 | 跨卷事务可能错位，需人工校验数据 |
Windows 场景对应 VSS 机制；主流云多数提供应用一致性快照选项，但通常需要安装代理并满足前置条件（应用支持、卷布局、代理运行状态），启用前要逐条核对。
冻结窗口要尽量短：fsfreeze 期间该文件系统的写入全部挂起，长时间冻结会导致应用阻塞甚至超时熔断，务必先在测试环境量出快照调用耗时。