云快照：魔法还是只是工具箱中的另一个工具？

不久前，我参加了一个演讲，该演讲讨论了云中的灾难恢复和业务连续性规划（DR/BCP），并提供了一个统计数据，将花费近8个小时的数TB数据库的备份与仅花费8秒的快照进行了比较！我想：“这个违背物理定律的快照魔法是什么？“因此，我努力找出快照的确切工作原理。

备份与快照——总体概述

您可能已经知道：备份是读取操作，随后写入到另一个位置以创建已读取内容的第二个副本的操作。第二个副本可以位于另一个磁盘/磁带上，也可以位于另一个数据中心/云环境中的对象存储中。备份要求对正在读取的任何内容进行独占锁定，以避免在进行复制时进行任何更改。有一些选项可以进行“联机备份”，这些选项不需要停止写入，但有一些性能注意事项。

与此不同，快照是在某个时间点对整个磁盘卷的精确、逐块复制。此操作发生在磁盘/硬件级别，而不是像备份那样发生在应用程序（或操作系统）级别，因此它的速度要快得多，侵入性也小得多。在一定程度上。我们仍然需要静止正在拍摄快照的磁盘并刷新任何内存缓冲区，但其时间比备份在整个读取操作的长度内所需的独占锁定要短得多。为了说明这一点，让我们更深入地研究我上面提到的8小时对比8秒的例子。

8小时对比8秒——你会得到什么？

完成8小时的备份后，您将在另一个位置拥有备份源的副本。对于数据库，您仍然需要将备份还原到数据库实例才能使用它。

在完成8秒左右的云快照后，您将标记所有已更改的块，以便以后可以将它们“懒洋洋地复制”到对象存储中以进行进一步处理。这里的关键点是您还没有数据的副本！您只有构成快照“标记”的块。在快照的这一部分，必须静止所有数据库活动，以确保数据库在所有节点上的完整性。这意味着所有读取和写入都需要通过“TPASUSPEND”命令暂停。标记操作完成后（根据卷上的块数，可能需要几秒钟或几分钟），数据库操作就可以恢复。后续的读取操作将继续不受阻碍地进行，但如果写入操作尝试更改标记为要复制的块，则快照进程必须先创建该块的副本，然后才能处理写入操作（请参见写入时复制）。对于具有繁重写入工作负载的系统，这可能会影响工作负载的性能，因为在写入之前必须创建每个块的副本。有一些方法可以通过将快照安排在繁重的写入活动期间（如批量加载窗口）来减轻这种影响。

快照完成……但这不是终点！

当为快照标记的块被云供应商复制到对象存储时，快照将显示为“正在处理”。在这一点上，我想指出，我之前提到过标记的块将被“懒洋洋地复制”。这意味着云快照过程的这一部分不保证将所有块复制到对象存储所需的时间内的任何SLA。这是在基于可用资源的后台发生的，而不是数据所有者可以控制的事情。

一旦它被标记为“完成”，您现在拥有的就是与源位于同一区域的对象存储（云快照）中的卷的副本。因此，在灾难情况下，您仍然得不到保护。现在，您必须将快照从对象存储复制到其他位置，最好是另一个云区域。

为了能够使用快照进行恢复，您需要以与最初快照相同的配置分配完全相同的存储量，然后将快照块“重新冻结”回新的存储卷。请记住，快照是存储的时间点副本，因此，如果您每12小时拍摄一次快照并保留最后4个快照，则可以恢复到已保留的4个快照期中的任何一个。如果用于灾难恢复目的，您通常会还原最新的快照，但请知道您有一定的灵活性，这与备份非常相似。

结论

回到最初的问题，“魔法还是工具箱中的另一个工具？”通常，快照是创建附加到计算节点的存储的完整副本的好方法。它们速度很快，与通过数据库引擎执行的等效备份操作相比，对工作负载的影响相对可以忽略不计。但它们不是魔法！它们只是一种能够将存储复制和还原到等效系统的不同方式，无论是在相同的云区域中还是完全位于不同的区域中。与备份相比，快照的缺点是没有对象级恢复功能。如果您有一个高价值对象已损坏，则无法像从备份中还原该对象那样仅从快照还原该对象。另一个缺点是，恢复到的系统在大小和配置上必须与原始系统相同，如果需要，可以将备份还原到不同大小的系统。底线是不要被“8小时对比8秒”的比较迷惑。虽然快照创建数据库副本所需的时间更少，但要完全防止灾难发生，则需要多于8秒的时间。