10.4 快照与备份
一句话
快照是同一份数据的时间点视图（快、省、与源共命运），备份是独立的一份副本（慢、贵、能独立恢复）；RPO 决定多久备一次，快照只能加速恢复，不能替代备份。
先分清四个概念
| 概念 | 数据在哪 | 独立性 | 主要用途 | 恢复速度 | 单位成本 |
|---|---|---|---|---|---|
| 快照 | 与原数据同一存储系统 | 低（同账号、同区域、同阵列） | 短周期恢复点、误删回滚、克隆环境 | 秒级挂载，数据按需加载 | 中（块存储单价） |
| 副本（replica） | 另一台机器/另一个 AZ | 中（同厂商、同账号常见） | 高可用、故障切换 | 秒~分钟 | 高（全量冗余） |
| 备份 | 独立介质/独立账号/异地 | 高（可离线、不可变） | 灾难恢复、合规留存、勒索恢复 | 分钟~小时 | 低（对象存储/归档） |
| 归档 | 低频介质 | 高 | 合规长期保留 | 小时级（取回延迟） | 最低 |
三个容易混淆的「快照」也要分清，它们同名但主场不同：
| 名称 | 含义 | 主场 |
|---|---|---|
| 存储快照 | 云盘/阵列的块级时间点副本 | 本节 |
| 数据库快照 | MVCC 下的一致性读视图 | 44.10 事务与隔离级别的实现 |
| 共识快照 | Raft 日志压缩后的状态机镜像 | 21.8 Raft：成员变更与快照 |
| 分布式快照 | Chandy-Lamport 全局状态 | 25.5 分布式快照 (Chandy-Lamport)（待补） |
快照为什么能「秒级」：COW / ROW / 元数据
| 机制 | 做法 | 写路径代价 | 典型场景 |
|---|---|---|---|
| COW（写时复制） | 写之前把旧块复制到快照区，源卷继续服务写 | 首次写旧块要额外复制一次 → 写放大 | 快照生命周期短、写少读多 |
| ROW（写时重定向） | 新数据写到新位置，快照保留旧位置 | 正常写路径不变，元数据更新 | 长期保留、克隆 |
| 元数据快照 | 只记录指针表，数据块共享 | 几乎为零 | 文件系统/分布式存储 |
云盘快照通常是块级增量 + 元数据：第一份全量，之后每次只存变化的块，恢复时按链拼装。
fio 能看到快照对写性能的影响（Linux，需先创建快照）：
# 无快照基线
fio --name=w --filename=/data/test.img --size=1G --rw=randwrite --bs=4k --iodepth=32 --runtime=30
# 创建快照后再跑同一条命令，对比 iops / clat
COW 快照保留越久，源卷每次写旧块都要复制一次，写放大越明显——快照不是「免费的时光机」，它把成本转移到了写路径。
一致性：崩溃一致 vs 应用一致
| 类型 | 怎么得到 | 恢复后像什么 | 适用 |
|---|---|---|---|
| 崩溃一致（crash-consistent） | 直接对运行中的卷打快照 | 像拔电重启：文件系统可修复，数据库靠 redo/WAL 前滚 | 无状态数据、能接受重放 |
| 应用一致（application-consistent） | 冻结写入（fsfreeze）、数据库进入备份模式、刷盘后再快照 | 事务边界完整，无需恢复 | 数据库、消息队列、多卷关联数据 |
数据库要恢复到「任意时间点」，光有快照不够，必须 快照 + WAL/binlog 连续归档：
一致性快照（基线） + 归档日志（增量） → 恢复到任意时刻（PITR）
🔑 只打快照不做日志归档，RPO 就是快照间隔；只归档日志不打基线快照，恢复要重放全量历史，RTO 不可控。两者是乘法关系，不是二选一。
多卷一致性：一个业务的数据盘和日志盘分别打快照，两个快照时间点不同 → 恢复后对不上。要么用存储的一致性组快照，要么停写后批量打。
备份的三要素
| 要素 | 要求 | 常见失分 |
|---|---|---|
| 3-2-1 | 3 份副本、2 种介质、1 份异地/离线 | 三份都在同一个云账号 |
| 不可变 | 对象锁（WORM）、保留策略、MFA delete | 备份账号可被同一把密钥删除 |
| 加密与密钥分离 | 静态加密 + 传输加密；密钥不与备份同库 | 密钥和备份放同一个 KMS/账号 |
| 可验证 | 定期恢复演练 + checksum 抽样 | 只看「备份任务成功」 |
| 可定位 | 备份目录/清单可查、版本可追溯 | 恢复时找不到「上周三那份」 |
「3-2-1」在云上的现代变体是 3-2-1-1-0：多一份离线/不可变，加「0 错误」——每次备份都要校验，恢复演练零失败。
算一笔账：快照不是免费的
设定：100 块 1 TiB 云盘，日变更率 5%，快照保留 7 天（1 份全量 + 6 份增量），单价按公开价目表量级。
| 方案 | 数据量 | 单价假设 | 月成本 |
|---|---|---|---|
| 块存储快照（7 天） | 130 TiB | $0.05/GB·月 | $6,656 |
| 同量放对象存储标准层 | 130 TiB | $0.023/GB·月 | $3,062 |
| 同量放对象存储归档层 | 130 TiB | $0.004/GB·月 | $532 |
| 每日全量备份保留 30 天 | 3,000 TiB | $0.023/GB·月 | $70,656 |
| 同上，归档层 | 3,000 TiB | $0.004/GB·月 | $12,288 |
每卷 7 天快照 = 1 TiB × (1 + 6 × 5%) = 1.30 TiB，恢复时要读 1.30 倍数据量。
三个结论：
- 每日全量保留 30 天是不可承受的（$70,656/月），必须用增量/差异 + 合成全量（策略见 36.2 备份策略）；
- 快照贵在块存储单价，备份便宜在对象存储单价：同样的字节，对象存储便宜一个数量级，代价是恢复慢、需要下载与解压；
- 恢复时间与数据量线性相关：1 TiB @ 200 MB/s ≈ 87.4 分钟，还没算解压、校验、日志重放。RTO 30 分钟的目标，靠单流恢复是做不到的，必须并行流 + 增量恢复 + 预置环境。
RPO / RTO 怎么落到策略
| 策略 | RPO | RTO（量级） | 成本 | 防什么 |
|---|---|---|---|---|
| 每小时快照，保留 7 天 | ≤ 1 小时 | 分钟级（挂载+按需加载） | 中 | 误删、错误发布、逻辑损坏 |
| 每日备份 + binlog 归档 | 秒~分钟（PITR） | 小时级（下载+重放） | 低 | 上述 + 长期留存 + 部分灾难 |
| 快照跨区复制 | 15 分钟~1 小时 | 小时级 | 中高 | 单区域故障 |
| 跨账号不可变备份 | 同备份周期 | 小时级 | 中 | 勒索软件、账号被盗 |
| 冷备/温备/热备 | 由复制方式决定 | 分钟~小时 | 高 | 机房级灾难 |
公式：
RPO = 备份/复制间隔 + 传输延迟
RTO = 检测 + 决策 + 准备环境 + 恢复数据 + 校验 + 切流
大多数团队只优化「恢复数据」这一段，忽略了检测与决策（谁批准恢复？恢复到哪个点？）和环境准备（集群、网络、密钥、证书）。演练时要给每一段计时。
恢复演练：唯一能证明备份有效的手段
| 演练项 | 做法 | 通过标准 |
|---|---|---|
| 数据完整性 | 抽样行数、checksum、关键业务查询 | 与源端一致（或差异可解释） |
| 应用可启动 | 恢复到隔离环境，跑一遍冒烟 | 服务能起、依赖能连 |
| 配置与密钥 | 备份里是否含配置、证书、密钥 | 缺一项就算失败 |
| 时长 | 每段计时，与 RTO 对比 | 总时长 ≤ RTO × 0.8（留余量） |
| 权限 | 恢复操作是否只需最小权限 | 不能依赖「某个人记得」 |
频率：核心系统每季度一次，非核心每半年一次；每次发布重大变更（库版本、存储引擎）后加一次。
反模式
| 反模式 | 后果 |
|---|---|
| 把快照当备份 | 源系统整体消失（账号被盗、区域故障）时快照一起没 |
| 备份与生产同账号、同密钥 | 勒索软件一次拿到删除权限，备份被一起加密/删除 |
| 备份不加密，或密钥与备份放一起 | 备份泄露 = 数据泄露；密钥丢失 = 备份作废 |
| 只备数据库，不备对象存储/配置/密钥 | 恢复后应用起不来，或缺图片/证书 |
| 从不演练，只看任务成功 | 真故障时恢复失败率极高；损坏的备份比没有更危险 |
| 增量链从不合成全量 | 链越长恢复越慢，中间坏一个全链作废 |
| 保留策略无限增长 | 存储成本线性上涨，且没人敢删 |
| 跨卷快照不对齐时间点 | 恢复后数据互相矛盾，业务手工修 |
| 备份窗口压在业务高峰 | 备份抢 IO，延迟上升，然后被「优化」掉 |
自检
Q1 快照秒级、备份小时级，为什么不能只用快照？
▸ 答案：快照与原数据同存储系统、同账号、同区域，独立性不足：账号被盗可以删快照、区域故障快照一起不可用、存储系统损坏快照也没了。快照防的是逻辑错误（误删、错误发布、批量改坏），恢复快是它的价值；备份防的是源系统整体消失，必须异地/离线/不可变。判断标准一句话：**源系统整体消失后，它还能独立恢复吗？**不能就不是备份。
Q2 崩溃一致性快照 + WAL 能恢复到哪个点？为什么还需要应用一致性快照？
▸ 答案：崩溃一致性快照相当于「拔电瞬间」，配合 WAL 前滚可以恢复到事务一致的状态（已提交的不丢、未提交的回滚），但恢复过程需要时间且依赖日志完整。应用一致性快照在打快照前冻结写入、刷盘、进入备份模式，恢复后不需要崩溃恢复，RTO 更短、风险更低；对多卷/多组件的业务（数据库+搜索索引+消息队列）尤其必要，否则各组件恢复到的时间点不一致。
Q3 100 卷 × 1 TiB、日变更 5%：7 天快照约 $6,656/月，每日全量备份保留 30 天约 $70,656/月。为什么差 10 倍以上？怎么把备份成本压下来？
▸ 答案：快照只存「首份全量 + 每天 5% 增量」，30 天全量则是每天一份 1 TiB × 100 卷 × 30 天 = 3,000 TiB，数据量差 23 倍（130 TiB vs 3,000 TiB），再叠加块存储与对象存储的单价差。压成本：增量/差异备份 + 定期合成全量（把链截断）、压缩与去重、冷数据下沉归档层、按业务分级设定保留期、只对关键数据做高频备份。
Q4 RTO 是 30 分钟，数据 1 TiB，单流恢复 200 MB/s 要 87 分钟。你至少要改哪三件事？
▸ 答案：① 并行恢复：多流/多线程拉取与写入，把有效吞吐提到 1 GB/s 以上（4–8 流）；② 增量/块级恢复：只恢复变化块，或先挂载快照按需加载、优先恢复热数据；③ 预置环境：恢复目标集群、网络、密钥、证书提前就绪，把「准备环境」从小时级压到分钟级。另外要把检测与决策流程自动化（谁批准、恢复到哪个点），否则 RTO 卡在人际流程上。
Q5 勒索软件场景下，快照和备份分别能不能救你？还需要什么？
▸ 答案：快照大概率救不了——攻击者拿到权限后通常先删快照/备份再加密数据；同账号、可写的快照是同一个攻击面。备份要能救你，必须满足：不可变（对象锁/WORM）、独立账号与独立凭证、离线或气隙、保留期长于攻击潜伏期。还需要：MFA delete、删除告警、恢复演练、以及「最小权限 + 凭证轮换」防止攻击者再次拿到备份账号。
跨篇相关：全量/增量/差异的成本结构与恢复链见 36.2 备份策略；冷备/温备/热备的形态见 36.3 冷备 / 温备 / 热备；跨机房副本与多活见 36.4 两地三中心与多活；RTO/RPO 的定义见 36.1 RTO / RPO；演练与验证见 36.7 演练与验证；块/文件/对象的语义见 10.1 块存储 / 文件存储 / 对象存储；对象存储的版本与生命周期见 10.2 对象存储语义；云盘 IOPS/吞吐模型见 10.3 云盘性能模型 (IOPS / 吞吐 / 时延)；备份数据的长期留存落在归档层，见 39.3 存储分级；WAL 与崩溃恢复见 44.2 存储引擎：WAL 与崩溃恢复。