我们的商店非常依赖 NetApp Volume Snapshots 进行备份。我们使用传统的基于代理的磁带备份进行一些但我们大部分系统都依赖快照。此外，我们没有严格的变更控制策略或任何集中配置管理，因此全部无论服务器所提供的数据是否已备份，我们的服务器都需要从裸机重建（并且没有任何实际文档）。自然，这使得快照成为管理的一个非常有吸引力的选择，因为我们可以恢复整个服务器，包括用户数据和配置。我们使用 NetApp 的虚拟存储控制台来制作基于 NFS 的 VMware 数据存储的快照，并使用 NetApp 的 SnapDrive 来制作直接呈现给客户的原始设备映射（物理）LUN。我们将关键快照异地 SnapMirror 到另一个文件服务器。当然，我们会定期测试我们的恢复过程。
我对我们对备份快照的依赖感到很不舒服。对我来说，一项技术要想被视为足够的备份策略，它需要满足以下标准：
- 备份必须是原子性的。也就是说，备份不能依赖任何其他东西来进行恢复。
- 备份需要与其备份的系统分离（带外）。
- 需要将备份复制或传输到远程站点（异地）
据我了解，NetApp 快照采用写入时重定向 (RoW) 方法。西弗吉尼亚文件布局使用一组指针（元数据？），这些指针实际上引用每个存储块，无论它在哪里。要制作快照，系统只需复制卷的元数据并将其存储在该卷的保留空间中。任何写入（创建/更改/删除）都会重定向到新块。这应该是 NetApp 的 WAFL 如此出色的秘诀，因为您不必像写时复制快照那样读取并将旧数据写入保留空间，然后将新数据写入旧数据。
我完全承认我可能不完全了解 NetApp 卷快照的工作原理，但如果我的理解或多或少正确的话，NetApp 快照就无法满足我的备份标准。
- 他们是不是原子性。“快照”实际上只是一组指向原始数据的指针。如果原始数据不再存在，元数据就毫无用处了。
- 快照与系统没有分离。如果有人删除了错误的卷，我就会丢失快照。如果 NetApp Filer 崩溃，我就会丢失备份。我可以使用 SnapMirror 将快照移动到另一个 Filer，但同样，这只是移动元数据，而不是实际块。如果我丢失了原始卷，我看不出复制到另一个 Filer 的快照有什么帮助。
有人能解释一下 NetApp Snapshots 为何被视为备份吗？我正在寻找主观评价良好答案，所以请用事实、参考和经验来支持你的立场。如果我对底层技术的理解不正确，请解释在哪里以及为什么会改变我的结论。如果您的商店依赖 NetApp Snapshots 作为备份，请提供足够的上下文信息，以便人们了解您必须满足什么样的恢复策略。
答案1
备份有两个功能。
- 首先，快照的作用是当数据不可用时，您可以恢复数据。从这个意义上讲，快照不是备份。如果您丢失了文件管理器上的数据（卷删除、存储损坏、固件错误等），那么该数据的所有快照也会丢失。
- 其次，更常见的是，备份用于纠正意外删除等常规问题。在此用例中，快照是备份。它们可以说是提供此类恢复的最佳方式之一，因为它们将数据的早期版本作为 .snapshot 隐藏目录直接提供给用户或其操作系统，用户可直接从该目录中读取文件。
无保留政策
话虽如此，虽然我们有快照并广泛使用它们，但我们仍然会在 Netbackup 上每晚将增量备份到磁带或数据域。原因是快照无法可靠地支持保留策略。如果您告诉用户他们将能够以每日粒度备份一周，然后以每周粒度备份一个月，那么您无法通过快照兑现这一承诺。
在具有快照的 Netapp 卷上，快照中包含的已删除数据会占用“快照保留”空间。如果卷未满，并且您已按此方式配置它，您还可以超越该快照保留，并让快照占用部分未使用的数据空间。但是，如果卷已填满，则除保留空间中的数据支持的快照外，所有快照都将被删除。删除快照取决于仅有的按可用快照空间，如果需要删除保留策略所需的快照，它就会删除。
考虑一下这种情况：
- 具有定期快照和 2 周保留要求的完整卷。
- 根据正常变化率，假设一半的储备用于快照。
- 有人删除了大量数据（超过快照保留量），暂时大幅增加了变化率。
此时，您的快照保留空间已完全使用，您允许 OnTap 用于快照的数据可用空间也已全部使用，但您尚未丢失任何快照。但是，一旦有人用数据重新填充卷，您将丢失数据部分中包含的所有快照，这会将您的恢复点推回到大量删除之后的时间。
概括
Netapp 快照无法防止真正的数据丢失。错误删除的卷或文件管理器上的数据丢失将需要您重建数据。
它们是一种非常简单而优雅的方法，可以实现简单的常规恢复，但它们不够可靠，无法取代真正的备份解决方案。大多数情况下，它们会使常规恢复变得简单而轻松，但当它们不可用时，您就会暴露。
答案2
他们是A是的，备份。我个人以前曾使用它们来代替每日增量备份，但我们仍然每周将完整备份写入磁带。
它们可以很好地防止任何非 netapp（系统访问卷）用户或管理员错误或问题。
它们无法防止 NetApp 本身发生灾难性硬件故障。我的理解是，SnapMirror 会将所有数据（在快照中）复制到另一个文件管理器[1]，因此将 SnapMirroring 复制到另一个文件管理器应该可以保护该数据集免受单个文件管理器发生灾难性故障的影响。
当然，一个主要问题是，如果管理 NetApp 的人删除了卷，那么所有快照都会随之删除。SnapMirror 到另一个文件管理器应该可以充分防止这种情况发生。
如果所有 NetApp 文件服务器都位于同一个数据中心，那么您就无法通过任何方式来应对重大灾难，而异地运送的磁带备份则可以为您提供这种服务。
如果您使用适当的 SnapManager 代理，您将获得更好的虚拟机和任何数据库（或类似数据库的东西）备份，该代理将在拍摄快照时协调短暂地使数据静止。如果给定的虚拟机及其数据完全包含在单个 NetApp 卷中，则该虚拟机的快照应该是崩溃一致的。也就是说，它应该和您拔掉服务器的电源插头并对驱动器进行映像一样好，这通常意味着文件系统检查和数据库等效项。如果数据库的数据在 LUN 之间分割，则似乎存在很大的数据损坏风险。
如果是我，我会将所有数据库设置为定期备份到本地磁盘，并将这些作业设置为保留一份或两份副本。这可以更好地保证可恢复性。
[1]http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us
答案3
你应该去读@罗勒现在的回答非常好，但我的看法如下：
快照不具备应用程序感知能力
仅仅因为您拍摄了底层存储卷的快照并不意味着该卷上的数据是可恢复的。MS SQL 就是一个很好的例子 - 您需要确保您的数据库在快照其使用的存储之前是事务一致的，否则@自由提到您不会比从硬故障中恢复更好。DBA 喜欢对 SQL 的不同部分使用不同的 LUN，以更好地利用存储系统，将临时数据库放在快速存储上，将系统数据库放在较慢的存储上，将只读或存档数据放在批量存储上，将工作数据放在两者之间。如果您只是对这些卷进行快照，那么高度您不太可能能够恢复数据库。
NetApp 提供了许多 Snap 工具，使快照具备应用程序感知能力。SnapManager for SQL 提供了这种感知能力。我相信在 Microsoft 生态系统中也有适用于 Exchange 和 SharePoint 的 SnapManager 工具。SnapDrive 没有这种应用程序感知能力。它只是提供了一种管理客户机内存储的便捷方法。
如果您将所有 IIS 数据和配置存储在 LUN 上并直接对这些 LUN 进行快照，则无法保证数据可恢复。问我我是怎么知道的...
多种存储类型可以有不同的快照计划
如果您以不同的方式向服务器呈现存储，这可能会使快照和恢复画面变得复杂。NetApp 的 ONTAP 是一种多协议产品，您很可能对特定服务器使用多种方法或存储类型。在我们的商店中，我们的一些服务器通过基于 NFS 的数据存储获取其 C:\ 驱动器，并通过原始设备映射 LUN 获取其“存储”驱动器。我们拍摄的是 RDM LUN 的快照，而不是基于 NFS 的数据存储。这使得恢复服务器变得非常困难，难的。
快照没有保证的保留策略
再次，@罗勒确实很好地涵盖了这一点，但值得重申。可以这样填充您的 Snap Reserve，即 Snpashot Autodelete 会删除未自然老化到删除的快照。再次。如果您或您的客户预计三周的快照可用，这可能会非常糟糕。
快照是内联的
这是集成存储的缺点……它确实……集成了。您的快照位于您正在备份的同一平台上。如果卷或文件服务器消失，您的备份也会消失。您可以通过使用 SnapMirror 将快照复制到另一个文件服务器来缓解这种情况，因为我在问题中错误地指出 SnapMirror 副本不是完整副本。
快照使不良的操作实践得以继续
我注意到的一件事是，快照使管理人员和客户能够继续糟糕的操作行为。在我们的环境中，我们的文档和配置管理实践非常糟糕。这意味着大多数服务器都以相同的基础（模板或映像）开始，但随后由不同的人员手动配置。随着服务器的使用寿命不断延长，它们与模板的差异越来越大，而这些差异通常不会记录或通过配置管理实现。
然后是快照！我们不需要退后一步来解决一些基本的操作实践，因为我们可以对所有服务器进行快照！我们可以使用 SnapMirror 将这些快照移出现场，以便将其用作备份！
我认为这是错误的教训。更好的教训是，配置管理框架，即使像变更日志一样简单，也应该备份，以便进行裸机恢复。快照是一个很棒的工具，但我认为过度依赖快照会让人忽视重要的基本原则。