3. 快照机制与备份的关系

在 vSphere 环境中，快照（Snapshot）常被误认为是一种备份手段。很多管理员在升级补丁、变更配置前会先打一个快照，事后便认为“数据已经安全了”。这种理解在单次短时操作中或许能救急，但一旦把它当作备份策略，就会在真正的灾难面前付出代价。要讲清楚快照与备份的关系，必须先理解快照的工作原理、快照链的形成方式，以及它对性能与存储的真实影响。

快照的工作原理：写时重定向

vSphere 快照并不是对虚拟机磁盘做一份完整拷贝，而是基于“写时复制/重定向”的思想，把磁盘状态在某一时刻“冻结”下来。以 VMFS 数据存储上的厚置备磁盘为例，当对虚拟机创建快照时，ESXi 会为该虚拟机每个磁盘生成一个增量磁盘文件（delta 磁盘，通常命名为 vmname-000001.vmdk），同时生成一份快照描述文件（.vmsd）和内存状态文件（若勾选“快照虚拟机内存”，还会产生 .vmsn 与 .vmem）。

创建快照后，虚拟机对磁盘的写入不再直接落到基础磁盘（base disk，即 vmname.vmdk），而是被重定向到增量磁盘。基础磁盘保持只读，代表快照那一刻的原始数据；增量磁盘记录此后所有变化。读取时，ESXi 需要先查增量磁盘，若数据不在增量磁盘中，再回落到基础磁盘。这就是“重定向写入”的核心逻辑。

需要特别说明的是，快照并不复制数据本身，它只是建立了一条“从当前状态回溯到过去状态”的引用链。因此快照创建极快、占用空间起初很小，但它的存在会改变虚拟机磁盘的 I/O 路径。

快照链：一层层叠加的增量

如果对同一虚拟机连续创建多个快照，就会形成快照链。例如先创建 Snapshot A，再创建 Snapshot B，此时磁盘结构为：基础磁盘 → A 的增量磁盘 → B 的增量磁盘。当前运行状态写入最顶层的增量磁盘，读取时若顶层没有数据，则逐层向下查找，直到基础磁盘。

快照链越长，读操作需要检查的层级越多，I/O 路径越复杂。删除中间某个快照时，ESXi 需要把该快照增量磁盘中的数据合并（consolidate）到相邻层，这个过程称为“快照合并”。合并期间会产生大量磁盘 I/O，若链过长或增量磁盘过大，合并可能持续数小时，甚至因空间不足而失败，导致虚拟机无法继续写入。

快照对性能与存储的影响

快照对性能的影响主要体现在三个方面。第一是写入放大：每次写入都要先判断目标数据是否已在增量磁盘中，若不存在则需在增量磁盘中分配新块，这比直接写基础磁盘多了一次元数据操作。第二是读取路径变长：读取一个块时，ESXi 需要从最顶层增量磁盘开始逐层查找，链越长，查找开销越大。第三是快照合并：删除快照时，ESXi 要把增量磁盘的数据合并回下层，这个过程会占用大量磁盘队列深度，可能影响同一数据存储上其他虚拟机的响应。

存储方面，增量磁盘会随着虚拟机写入不断增长。一个常见的误区是“快照占用空间等于虚拟机磁盘大小”，实际上增量磁盘只记录变化块，初始很小，但若虚拟机持续写入大量数据（如数据库日志、系统更新），增量磁盘可能迅速膨胀到数十甚至上百 GB。如果数据存储剩余空间不足以容纳增量磁盘增长和后续合并所需的临时空间，快照就会进入“空间不足”状态，虚拟机可能被暂停，业务中断。

快照作为临时恢复手段的适用场景与局限

快照真正适用的场景是“短时、可预期、可回退”的变更操作。例如：为虚拟机安装补丁前创建快照，若补丁导致系统异常，可在数分钟内回退到打补丁前的状态；升级某应用前创建快照，验证新版本不兼容时快速还原；进行配置变更或驱动更新前创建快照，作为变更窗口内的安全垫。这些场景的共同点是：变更时间短、变更后很快验证、验证通过后立即删除快照。

快照的局限同样明确。它无法应对基础磁盘或数据存储级别的故障：如果承载基础磁盘的 LUN 损坏，快照链上的所有文件都可能丢失，快照无法恢复。它也无法应对误删除虚拟机、数据存储格式化、站点级灾难等场景。此外，快照回退会丢失创建快照之后的所有写入，若业务在快照期间持续产生数据，回退意味着这部分数据永久丢失。快照还不能替代文件级恢复：若只想恢复某个文件，回退整个快照会连带回退其他无关变更。

快照与备份的本质区别

理解两者区别，关键看四个维度：数据副本的独立性、存储位置、恢复粒度和保留周期。

一句话概括：快照是“时间点回退开关”，备份是“独立可恢复副本”。快照解决的是“改错了怎么快速退回去”，备份解决的是“数据没了怎么重新拿回来”。两者可以配合使用——例如备份软件在创建备份前先打一个快照，利用快照的静默能力获取一致性的备份数据，备份完成后立即删除快照。在这种配合中，快照只是备份过程中的一个临时环节，真正承担数据保护职责的仍然是备份副本本身。