NetApp 快照可以用作备份吗？

Question

我们的商店非常依赖 NetApp Volume Snapshots 进行备份。我们对一些数据使用传统的基于代理的磁带备份，但总的来说，我们大多数系统都依赖于快照。此外，我们没有严格的变更控制政策或任何集中的配置管理，因此所有我们的服务器，无论其服务提供的数据是否备份，都需要从裸机（并且没有任何真正的文档）重建。自然地，这使得快照对于管理来说是一个非常有吸引力的提议，因为我们可以只恢复整个服务器、用户数据和包括的配置。我们使用 NetApp 的虚拟存储控制台为我们基于 NFS 的 VMware 数据存储创建快照，并使用 NetApp 的 SnapDrive 为直接呈现给来宾的原始设备映射（物理）LUN 制作快照。我们将关键快照异地快照镜像到另一个 Filer。当然，我们会定期测试我们的恢复过程。

我不禁对我们对备份快照的依赖感到不舒服。对我而言，对于被视为足够作为备份策略的技术，它需要满足以下标准：

• 备份需要是原子的。也就是说，备份不能依靠其他任何东西来恢复。
• 备份需要与它作为备份的系统分离（带外）。
• 备份需要复制或传输到远程站点（异地）

据我了解，NetApp 快照在写入时重定向 (RoW) 方法下工作。在WAFL文件格式使用一组指针（元数据）指出实际引用存储在以往任何时候这可能是每个块。要制作快照，系统只需复制卷的元数据并将其存储在该卷的保留空间中。任何写入（创建/更改/删除）都被重定向到新块。这应该是使 NetApp 的 WAFL 如此出色的特殊调味料，因为您不必进行读取，然后将旧数据写入保留空间，然后将新数据写入旧数据，例如 Copy-On-Write 快照。

我完全承认我可能不完全理解 NetApp 卷快照的工作原理，但如果我的理解或多或少正确，NetApp 快照无法满足我的备份标准。

• 它们不是原子的。“快照”实际上只是一组指向原始数据的指针。如果原始数据不再存在，元数据将毫无用处。
• 快照不与系统分离。如果有人删除了错误的卷，我就会丢失快照。如果 NetApp Filer 爆炸成很小的小猫，我就会失去备份。我可以使用 SnapMirror 将我的快照移动到另一个 Filer，但同样，它只是移动元数据而不是实际块。如果我丢失了原始卷，我看不出复制到另一个 Filer 的快照将如何提供帮助。

有人能解释一下 NetApp 快照如何被视为备份吗？我正在寻找好的主观答案，所以请用事实、参考和经验来支持你的立场。如果我对底层技术的理解不正确，请解释在哪里以及为什么会改变我的结论。如果您的商店依赖 NetApp Snapshots 作为备份，请提供足够的上下文信息，以便人们了解您必须满足什么样的恢复策略。

Answer 1

备份有两个功能。

• 首先，如果数据不可用，它们可以让您恢复数据。从这个意义上说，快照不是备份。如果您丢失文件管理器上的数据（卷删除、存储损坏、固件错误等），该数据的所有快照也会消失。
• 其次，更常见的是，备份用于纠正意外删除等常规事件。在此用例中，快照是备份。它们可以说是提供这种恢复的最佳方法之一，因为它们使早期版本的数据作为 .snapshot 隐藏目录直接提供给用户或他们的操作系统，他们可以直接从中读取他们的文件。

无保留政策

也就是说，虽然我们拥有快照并广泛使用它们，但我们仍然在 Netbackup 上每晚对磁带或数据域进行增量。原因是快照不能可靠地支持保留策略。如果您告诉用户他们可以从每日粒度备份一周，然后按周粒度备份一个月，那么您就无法通过快照来兑现承诺。

在带有快照的 Netapp 卷上，包含在快照中的已删除数据会占用“快照保留”空间。如果卷未满并且您已经以这种方式对其进行了配置，则您还可以推送超过该快照保留并拥有占用一些未使用数据空间的快照。但是，如果卷已满，则除保留空间中的数据支持的快照之外的所有快照都将被删除。快照的删除仅由可用的快照空间决定，如果需要删除保留策略所需的快照，它会删除。

考虑这种情况：

• 具有常规快照和 2 周保留要求的完整卷。
• 根据正常的变化率，假设有一半的预留用于快照。
• 有人删除了大量数据（超过快照保留），暂时大幅增加了更改率。

此时，您的快照预留已完全使用，您允许 OnTap 用于快照的可用数据空间也已完全使用，但您还没有丢失任何快照。但是，一旦有人用数据填充卷备份，您将丢失数据部分中包含的所有快照，这会将您的恢复点推回到大删除之后的时间。

概括

Netapp 快照无法让您避免真正的数据丢失。文件管理器上的错误删除卷或数据丢失将需要您重建数据。

它们是一种非常简单和优雅的方式来允许简单的例行恢复，但它们不够可靠，无法取代真正的备份解决方案。大多数情况下，他们会让日常恢复变得简单而轻松，但是当他们不可用时，您就会暴露在风险中。

Answer 2

他们是一个备份，是的。我个人以前曾用它们代替每日增量，但我们仍然每周进行一次完整的录音。

它们可以很好地防止任何非 netapp（访问卷的系统）用户或管理员错误或问题。

它们不能防止 netapp 本身的灾难性硬件故障。我的理解是 SnapMirror 确实将所有数据（在快照中）复制到另一个文件管理器 [1]，因此 SnapMirroring 到另一个文件管理器应该保护该数据集免受单个文件管理器的灾难性故障。

当然，一个主要问题是，如果管理 netapp 的人删除了该卷，那么所有快照都会随之删除。SnapMirror 到另一个文件管理器应该足以防止这种情况发生。

如果您的所有 NetApp 文件管理器都位于同一个数据中心，那么您就没有任何内容来应对重大灾难，而磁带备份会以异地传送的方式为您提供。

如果您使用适当的 SnapManager 代理，您将获得更好的 VM 和任何数据库（或类似数据库的东西）的备份，该代理将在拍摄快照时短暂地协调停止数据。如果给定的 VM 及其数据完全包含在单个 NetApp 卷中，则该 VM 的快照应该是崩溃一致的。也就是说，它应该就像您拔掉服务器上的插头并对驱动器进行映像一样好，这通常意味着文件系统检查和数据库等效项。如果数据库的数据在 LUN 之间拆分，则数据损坏的风险似乎很大。

如果是我，我会将所有数据库设置为定期备份到本地磁盘，并将这些作业设置为保留一两个副本。这为您提供了更好的可恢复性保证。

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us