NetApp快照可以用作备份吗？

备份有两个function。

• 首先，他们在那里允许你恢复你的数据，如果它变得不可用。 从这个意义上说，快照不是备份。 如果在文件pipe理器上丢失了数据（卷删除，存储损坏，固件错误等），那么该数据的所有快照也都会丢失。
• 其次，更常见的是，备份被用来纠正例如意外删除等常规事务。 在这个用例中，快照是备份。 他们可以说是提供这种恢复的最佳方式之一，因为他们可以将早期版本的数据直接提供给用户或他们的操作系统，作为一个.snapshot隐藏目录，以便他们可以直接读取文件。

没有保留政策

也就是说，虽然我们有快照并广泛使用，但我们仍然在Netbackup上每晚进行磁带或数据域增量备份。 原因是快照不能可靠地维护保留策略。 如果您告诉用户，他们将能够从一个星期的每日粒度备份一个月，而每个星期的粒度为一个月，则无法使用快照保留该承诺。

在具有快照的Netapp卷上，快照中包含的已删除数据占用“快速预留”空间。 如果卷未满并且已经以这种方式进行了configuration，则还可以推送该快照保留，并获得占用一些未使用的数据空间的快照。 但是，如果卷填满了，所有的快照，但保留空间中的数据所支持的快照都将被删除。 删除快照仅由可用的快照空间确定，如果需要删除保留策略所需的快照，则快照将会删除。

考虑这种情况：

• 全卷定期快照和2周保留要求。
• 根据正常的变化率，假设一半的储备用于快照。
• 有人删除了大量数据（超过了快照储备），暂时大幅提高了变化率。

此时，您的快照保留已被完全使用，因为您已允许OnTap用于快照的数据可用空间尽可能多，但您还没有丢失任何快照。 只要有人用数据填满备份卷，就会丢失数据部分中包含的所有快照，这会将恢复点恢复到大删除之后的时间。

概要

Netapp快照不会掩盖真正的数据丢失。 文件pipe理器上错误的删除卷或数据丢失将需要您重build数据。

它们是一种非常简单而优雅的方法，可以进行简单的日常恢复，但它们不够可靠，无法替代真正的备份解决scheme。 大多数情况下，他们会进行简单而无痛的日常恢复，但是当他们无法使用时，就会暴露出来。

他们是一个备份，是的。 我以前曾经亲自使用它们来代替每日增量，但是我们仍然每周都会使用磁带。

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

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

当然，一个主要的问题是，如果pipe理netapp的人删除音量，那么所有的快照都会随之而来。 SnapMirror到另一个Filer应该充分防止这种情况。

如果您所有的NetApp归档人员都在同一个数据中心内，那么您就没有任何重大的灾难发生，磁带备份运送到外部的方式将会带给您。

如果您使用适当的SnapManager代理，您将可以更好地备份虚拟机和任何数据库（或类似数据库的事物），SnapManager代理将在拍摄快照时暂时协调数据的静默。 如果给定的虚拟机及其数据完全包含在单个NetApp卷中，则该虚拟机的快照应该是崩溃一致的。 也就是说，它应该与您将服务器上的插件拔下并对驱动器进行映像一样好，这通常意味着文件系统检查和数据库等价物。 如果数据库的数据在LUN之间分裂，似乎存在数据损坏的重大风险。

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

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

你现在应该去读@Basil的优秀答案，但这是我的两分钱：

快照不是应用程序感知的

仅仅因为您拍摄底层存储卷的快照并不意味着该卷上的数据是可恢复的。 MS SQL就是一个很好的例子 – 在快照所使用的存储之前，你需要确保你的数据库是事务一致的，否则就像@freiheit提到你不能比从硬件故障中恢复一样好。 数据库pipe理员喜欢在SQL的不同部分使用不同的LUN，以便更好地利用存储系统，快速存储上的临时数据库，速度较慢的存储上的系统数据库，大容量存储上的只读或归档数据以及两者之间的工作数据。 如果您只是对这些卷进行快照，那么您将不可能恢复数据库。

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

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

多种存储types可以有不同的快照计划

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

快照没有有保证的保留策略

再次， @Basil真的涵盖了这一点，但值得重申。 可以用Snpashot Autodelete删除没有自然老化的快照删除快照，以填充快照储备。 再次。 如果您或您的客户预期三周的快照可用，这可能会非常糟糕。

快照是内联的

这是集成存储的缺点…它很好…集成。 您的快照驻留在您正在备份的同一平台上。 如果音量或Filer消失，您的备份也会消失。 您可以通过使用SnapMirror将快照复制到另一个Filer来缓解此问题，因为我在SnapMirror副本不是完整副本的问题中错误地声明了这一点。

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

我注意到的一件事是，快照使经理和客户能够继续糟糕的操作行为。 在我们的环境中，我们有很差的文档和configurationpipe理实践。 这意味着大多数服务器都以相同的基础（模板或图像）开始，然后由不同的人员手动configuration。 当它们延续其生命时，服务器以通常不被logging或通过configurationpipe理实施的方式与模板分离得越来越远。

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

我认为这是在这里学习的错误教训。 更好的教训是，为了裸机还原的目的，应该备份configurationpipe理框架，即使它像更新日志一样简单。 快照是一个非常棒的工具，但是我可以过度依赖这些工具来遏制重要的基本面。