NetApp快照可以用作备份吗？

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

对于我们对备份快照的依赖，我不禁感到不自在。对我来说，要使一项技术被视为足以作为一种备份策略，它需要满足以下条件：

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

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

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

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

有人可以解释如何将NetApp快照视为备份吗？我正在寻找良好的主观答案，因此请以事实，参考和经验来支持您的立场。如果我对基本技术的理解不正确，请解释在何处以及为什么会改变我的结论。如果您的商店依赖NetApp快照作为备份，请提供足够的上下文信息，以便人们可以了解您必须满足哪种恢复策略。

备份具有两个功能。

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

没有保留政策

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

在具有快照的Netapp卷上，快照中包含的已删除数据将占用“快照保留”空间。如果卷未满，并且已通过这种方式配置，则还可以超过该快照保留空间，并使快照占用一些未使用的数据空间。但是，如果卷已满，保留空间中数据支持的快照以外的所有快照都将被删除。快照的删除仅由可用的快照空间确定，如果需要删除保留策略所需的快照，它将删除快照。

考虑这种情况：

• 具有常规快照的完整卷，需要2周的保留时间。
• 假定基于正常变化率的快照使用了一半的保留。
• 有人删除了很多数据（超过了快照保留），从而极大地提高了更改速度。

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

摘要

Netapp快照无法防止实际数据丢失。错误的删除卷或文件管理器上的数据丢失将要求您重建数据。

它们是允许进行简单例行还原的非常简单而优雅的方法，但是它们不够可靠，无法替代真正的备份解决方案。在大多数情况下，它们会使日常还原变得简单而轻松，但是当它们不可用时，您就会无所适从。

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

它们可以很好地防止任何非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

您现在应该阅读@Basil的出色答案，但这是我的两分钱：

快照不支持应用程序

仅仅因为您对基础存储卷进行了快照并不意味着该卷上的数据是可恢复的。MS SQL是一个很好的例子-您需要先确保数据库是事务一致的，然后再对正在使用的存储进行快照，否则@freiheit提到，您比从硬故障中恢复更好。DBA喜欢为SQL的不同部分使用不同的LUN，以更好地利用存储系统，快速存储上的临时数据库，慢速存储上的系统数据库，大容量存储上的只读或存档数据以及介于两者之间的工作数据。如果仅对那些卷进行快照，则极不可能恢复数据库。

NetApp提供了许多Snap工具来使快照了解应用程序。SnapManager for SQL提供了这种认识。我相信在Microsoft生态系统中，还有用于Exchange和SharePoint的SnapManager工具。SnapDrive没有此应用程序意识。它只是提供了一种方便的方法来管理来宾内的存储。

如果要将所有IIS数据和配置存储在LUN上，并直接快照这些LUN，则不能保证数据可恢复。问我我怎么知道...

多种存储类型可以具有不同的快照计划

如果以不同的方式向服务器提供存储，这会使快照和恢复图片变得复杂。NetApp的ONTAP是一种多协议产品，对于特定的服务器，您很可能使用多种方法或存储类型。在我们的商店中，我们的某些服务器通过基于NFS的数据存储区获得其C：\驱动器，并通过原始设备映射的LUN获得其“存储”驱动器。我们正在拍摄RDM LUN的快照，而不是基于NFS的数据存储的快照。这使得恢复服务器非常困难。

快照没有保证的保留策略

同样，@ Basil确实涵盖了这一点，但值得重申。可以通过Snpashot Autodelete删除尚未自然老化以删除的快照的方式来填充快照储备。再次。如果您或您的客户期望三周的快照可用，这可能会非常糟糕。

快照是内联的

这是集成存储的缺点。快照驻留在要备份的同一平台上。如果卷或Filer打开，则备份也将消失。您可以通过使用SnapMirror将快照复制到另一个Filer来减轻这种情况，正如我在问题中错误地指出SnapMirror副本不是完整副本一样。

快照使不良的操作习惯得以继续

我注意到的一件事是快照使经理和客户能够继续执行可怕的操作行为。在我们的环境中，我们的文档和配置管理实践非常差。这意味着大多数服务器以相同的基础（模板或映像）开头，然后由不同的人员手动配置。随着服务器寿命的延长，服务器与模板之间的差异会越来越大，其配置方式通常不会通过配置管理来记录或实现。

然后来快照！我们不需要退后一步来解决一些基本的操作实践，因为我们可以快照所有服务器！而且我们可以使用SnapMirror将这些快照移到异地，这样我们就可以将它们用作备份！

我认为这是在这里学习错误的课程。一个更好的经验教训是，即使是变更日志一样简单的配置管理框架，也应该出于裸机还原的目的而进行备份。快照是一种很棒的工具，但是我可以诱惑一下，过度依赖快照来抑制重要的基础知识。