2、快照技术基础：写时复制（COW）原理、差异快照与全量快照、快照链与依赖关系

快照技术，说白了就是给数据拍一张「瞬间照片」。你想想看，一个几百 GB 的磁盘，要在几秒钟内完成备份，传统拷贝肯定不行。那存储系统是怎么做到的？核心秘密就在我今天要讲的这几个技术点上。

我在运维生涯早期，第一次接触快照时也觉得这东西很玄乎。直到有一次线上数据库误操作，靠着一份 5 分钟前的快照，10 秒就恢复了数据。嗯，从那以后，我对快照的敬畏心就建立起来了。

写时复制（Copy-On-Write，简称 COW）是快照最底层的实现机制。它的核心思想很简单：创建快照时不复制任何数据，只在数据被修改时才复制原始数据块。

具体流程是这样的：

关键理解：COW 的本质是「用元数据换时间」。创建快照几乎瞬间完成，但写入性能会受一定影响——因为首次修改需要先复制再写入。

我在项目中遇到过一种极端情况：一个 2TB 的数据库卷，创建快照后立即进行全量数据更新。结果 COW 操作导致写入延迟飙升了 3 倍。后来我们调整了快照策略，在业务低峰期才创建快照，才解决了这个问题。

下面这张图展示了 COW 的核心流程：

我的经验：COW 快照的预留空间大小很关键。我一般建议预留源卷大小的 20%-30%。如果预留空间写满，快照就会失效，数据完整性就无法保证了。

理解了 COW 原理，我们再来看两种常见的快照类型。全量快照和差异快照，它们的应用场景完全不同。

全量快照，就是完整复制所有数据。我记得有一次做数据中心迁移，给 10 台物理机各做了一次全量快照，光等待就花了 4 个小时。但恢复时确实爽，直接挂载就能用。

差异快照则聪明得多。它只记录「从上一次快照以来，哪些数据块发生了变化」。你想想看，一个 1TB 的数据库，每天可能只变化 10GB 数据。用差异快照，每天只需要 10GB 的存储空间，而不是 1TB。

注意：差异快照有一个致命弱点——它依赖链上的所有前置快照。如果中间某个快照损坏了，后面所有的差异快照都无法恢复。我曾经见过一个团队因为删除了中间的一个差异快照，导致后面 30 天的备份全部失效。

快照链，就是把多个快照按照时间顺序串联起来。每个快照都依赖前一个快照的数据。这个依赖关系，是理解快照恢复和删除的关键。

快照链的结构是这样的：

下面这张图展示了快照链的依赖关系：

快照链的依赖关系，决定了删除操作的风险。举个例子：

我曾经踩过的坑：有一次清理存储空间，我直接删除了一个基础快照，以为后面的增量快照还能用。结果恢复时才发现，所有依赖这个基础快照的增量快照全部变成了「孤儿数据」，完全无法恢复。那次事故让我损失了 3 天的备份数据。从那以后，我每次删除快照前都会先检查依赖关系。

在实际运维中，快照技术有几个关键点需要特别注意：

我的建议：对于核心业务系统，我习惯采用「全量+差异」的混合策略。每周做一次全量快照，每天做一次差异快照。这样既控制了存储成本，又保证了恢复的可靠性。而且，我会定期验证快照的可恢复性——别等到真出事了才发现快照是坏的。

快照技术看似简单，但里面的门道不少。COW 原理决定了快照的性能特征，全量和差异快照决定了存储策略，快照链的依赖关系则直接关系到数据安全。把这些基础打牢了，后面讲镜像回滚保护机制时，你就能理解为什么回滚操作需要依赖快照链来保证一致性了。