3. 快照的实现方式：全量与增量、差异与永久增量、文件系统与卷

快照这东西，说白了就是给数据拍个“定妆照”。但怎么拍、拍完怎么存，这里面的门道可不少。我最早接触快照时，以为就是把数据全拷贝一份，后来才发现——嗯，要是真这么干，存储阵列早被撑爆了。

这一章，我们聊聊快照的几种主流实现方式。你理解了他们，就能在生产环境里做出更靠谱的选择。

3.1 全量快照 vs 增量快照

这是最基础的一组概念。全量快照，就是把源数据完整复制一份。增量快照，只记录从上一次快照之后发生变化的数据块。

3.1.1 全量快照

全量快照的实现很简单。系统在某个时间点，把源卷的所有数据块都拷贝到目标位置。我早期做备份方案时，经常用全量快照做周备——虽然慢，但恢复起来特别痛快，一个命令就搞定。

优点：

• 恢复速度快，不需要依赖其他快照
• 数据完整性高，独立性强

缺点：

• 占用空间大，每次都是全量拷贝
• 创建时间长，尤其是大卷

3.1.2 增量快照

增量快照只记录变化的数据块。第一次做全量，后面每次只存“差异”。

举个例子：一个100GB的数据库卷，每天只变化2GB数据。用全量快照，每天占100GB；用增量快照，第一天100GB，后面每天只占2GB。你想想看，这空间节省有多明显。

但要注意：增量快照的恢复链路比较长。如果你有10个增量快照，恢复时得先把全量恢复，再依次应用10个增量。中间任何一个快照损坏，后面的数据都悬了。

对比维度	全量快照	增量快照
空间占用	高（每次全量）	低（只存变化）
创建速度	慢	快
恢复速度	快（单次恢复）	慢（需链式恢复）
数据独立性	高	低（依赖前序快照）
典型场景	周备、基线备份	小时级/分钟级备份

3.2 差异快照 vs 永久增量快照

这两者容易搞混。我刚开始也分不清，直到在项目里踩了坑才彻底弄明白。

3.2.1 差异快照

差异快照，记录的是从“上一次全量快照”之后的所有变化。注意，不是从上一次快照，而是从最近一次全量快照。

举个例子：周一做全量，周二做差异（记录周一之后的变化），周三再做差异（还是记录周一之后的变化）。周三的差异快照，包含了周二和周三两天的变化量。

3.2.2 永久增量快照

永久增量快照，是增量快照的进化版。它只做一次全量基线，之后永远只记录增量变化。但它的厉害之处在于——恢复时不需要链式恢复。

怎么做到的？原理是：每个增量快照内部维护了一个“指针映射表”，指向全量基线中的原始数据块。如果某个数据块从未被修改，指针直接指向基线；如果被修改过，指针指向最新的增量副本。

说白了，永久增量快照在“写”的时候是增量的，在“读”的时候看起来像全量的。

3.3 基于文件系统的快照 vs 基于卷的快照

这一组是从实现层面来划分的。一个在文件系统层工作，一个在存储卷层工作。

3.3.1 基于文件系统的快照

文件系统快照，由文件系统自身管理。比如ZFS、Btrfs、LVM的快照功能。它工作在操作系统层面，能感知文件、目录、权限这些高层语义。

特点：

• 粒度细：可以针对单个文件或目录做快照
• 空间效率高：通常使用写时复制（CoW）技术
• 依赖文件系统：换文件系统就不灵了

我记得有次给一个Linux服务器做数据保护，用的就是ZFS快照。ZFS的快照几乎是瞬间完成，而且创建快照时对业务几乎无影响。当时数据库跑着OLTP负载，我一条命令下去，快照就生成了，IO延迟一点没变。

# ZFS创建快照示例
zfs snapshot tank/data@snap_2024_01_15

# 回滚到快照
zfs rollback tank/data@snap_2024_01_15

# 查看快照列表
zfs list -t snapshot

3.3.2 基于卷的快照

卷快照，由存储系统（硬件或软件）在卷管理层实现。它不关心卷里装的是什么文件系统，只关心数据块。

特点：

• 通用性强：支持任何文件系统，甚至裸设备
• 性能稳定：由存储控制器处理，不消耗主机CPU
• 管理集中：可以在存储阵列上统一管理

3.4 核心逻辑关系图

下面这张图，把本章的核心概念串起来了。你可以看到快照从“实现方式”到“应用场景”的完整脉络。

3.5 如何选择？

没有银弹。不同的场景，适合不同的快照方式。我列几个典型场景，你可以对照参考：

1. 数据库高频保护：永久增量快照 + 卷快照。空间省，恢复快，对数据库影响小。
2. 文件服务器日常备份：增量快照 + 文件系统快照。粒度细，可以按文件恢复。
3. 容灾基线同步：全量快照。独立性强，适合跨站点传输。
4. 开发测试环境：差异快照 + 文件系统快照。方便快速回滚，空间占用可控。