EBS 快照为何增量备份却能完整恢复 - 块级差异管理的内部机制
从块级差异管理、S3 存储结构、快速快照恢复的内部机制解析 EBS 快照作为增量备份却能从任意快照完整恢复卷的原理。
增量备份的基本概念
EBS 快照是增量备份。第一个快照是整个卷的副本，但第二个及之后的快照仅保存自上次快照以来变更的块。对于 100GB 的卷，如果快照间有 5GB 数据变更，第二个快照仅消耗 5GB 存储。这种增量方式大幅减少了快照创建时间和存储成本。但这里产生了一个疑问：如果是增量备份，恢复时不是需要按顺序应用第一个完整备份加所有增量吗？传统磁带备份确实如此，但 EBS 快照采用不同的机制。
块级引用结构
EBS 快照的内部结构是以块（通常 512KB）为单位的指针表。每个快照持有卷所有块的指针。变更的块作为新数据保存，未变更的块引用前一个快照的数据。举例说明：假设卷由 100 个块组成。快照 A 保存全部 100 个块的数据。快照 B 中块 5 和 10 发生变更，保存这 2 个新数据，其余 98 个引用快照 A 的数据。快照 C 中块 3 和 5 发生变更，保存这 2 个新数据，其余引用快照 B（或其引用的 A）的数据。这种结构使得从任何快照都能追溯所有块的数据。从快照 C 恢复时，块 3 和 5 使用 C 的数据，块 10 使用 B 的数据，其余使用 A 的数据。引用解析由 EBS 内部自动完成，用户无需关注增量顺序。
快照删除与引用重构
增量备份中最容易混淆的是删除中间快照时的行为。假设有快照 A → B → C，删除 B 会怎样？传统增量备份中删除 B 会导致 C 无法恢复。但 EBS 快照可以安全删除 B。删除 B 时，仅由 B 持有的块（在 B 中变更但在 C 中未变更的块）数据会合并到 C 中。即 C 的指针表被更新，原来引用 B 的指针改为直接引用 A 的数据或合并后的数据。这一合并处理由 EBS 内部自动完成。结果是无论删除哪个快照，都不影响其余快照的恢复。即使删除第一个快照 A，B 和 C 也能正常恢复，因为仅由 A 持有的块数据会合并到 B 中。
快照存储位置与恢复延迟
EBS 快照数据保存在 S3 中。但不是用户的 S3 存储桶，而是 AWS 管理的内部 S3 基础设施，因此无法从 S3 控制台直接查看快照数据。从快照恢复卷时，数据从 S3 传输到 EBS 存储基础设施。重要的是，恢复采用「延迟加载」（Lazy Loading）方式。卷创建立即完成，但所有块从 S3 传输完毕需要时间。访问尚未传输的块时，会即时从 S3 按需获取。这种延迟加载导致首次访问时延迟增加的「首次触碰惩罚」。在生产环境中避免此惩罚，可启用 Fast Snapshot Restore（FSR）。FSR 将快照数据预加载到 EBS 存储基础设施，使恢复后立即可以全性能访问。FSR 费用为每个启用的可用区每小时 0.75 USD。
EBS Snapshots Archive - 降低成本的选择
2021 年推出的 EBS Snapshots Archive 可将低访问频率的快照移至最多便宜 75% 的存储层。普通快照每 GB 月费 0.05 USD，Archive 层为 0.0125 USD。但从 Archive 层恢复需要 24 至 72 小时。Archive 适用于合规要求需长期保留但无需频繁访问的快照。例如，法规要求月度完整备份保留 7 年时，可将最近 3 个月的快照保留为普通快照，之前的移至 Archive，大幅降低存储成本。快照生命周期管理可通过 Amazon Data Lifecycle Manager（DLM）自动化。DLM 按计划自动创建快照，按保留期自动删除旧快照，还可自动化向 Archive 层的迁移。要系统学习 EBS 备份设计，专业书籍 (Amazon)可供参考。