我们的商店非常依赖NetApp卷快照进行备份。 对于我们的一些数据,我们使用传统的基于代理的磁带备份,但总的来说,我们依赖大部分系统的快照。 此外,我们没有严格的变更控制策略或任何集中的configurationpipe理,因此我们所有的服务器(无论其服务提供的数据是否已备份)都需要从裸机(并且没有任何实际文档)进行重build。 当然,这使得快照成为一个非常有吸引力的pipe理命题,因为我们可以恢复整个服务器,用户数据和configuration。 我们使用NetApp的虚拟存储控制台来创build我们基于NFS的VMware数据存储的快照,以及直接提供给客户的原始设备映射(物理)LUN的NetApp SnapDrive。 我们将SnapMirror关键快照异地传送到另一个Filer。 当然,我们经常testing我们的恢复过程。
我不禁感到不舒服,因为我们依赖备份的快照。 对于我来说,对于一种被认为足够作为备份策略的技术,它需要满足以下标准:
我的理解是,NetApp Snapshots采用redirect写(RoW)方法进行工作。 WAFL文件布局使用一组指针(元数据?),实际上可以引用每个存储块。 为了创build快照,系统只需获取卷的元数据副本并将其保存在该卷的保留空间中。 任何写入(创build/更改/删除)都会被redirect到新的块。 这应该是让NetApp的WAFL如此之好的特别之处,因为您没有进行读取操作,然后将旧数据写入保留空间,然后将新数据写入像Copy-On-Write快照这样的旧数据。
我完全承认,我可能不明白NetApp卷快照如何工作,但如果我的理解正确或多或less,NetApp快照无法满足我的备份标准。
有人可以解释NetApp快照如何被视为备份吗? 我正在寻找良好的主观答案,所以请支持你的立场与事实,参考和经验。 如果我对底层技术的理解是错误的,请解释我的结论改变的地方和原因。 如果您的商店依赖NetApp Snapshots作为备份,请包含足够的上下文信息,以便人们可以了解您必须满足哪种恢复策略。
备份有两个function。
没有保留政策
也就是说,虽然我们有快照并广泛使用,但我们仍然在Netbackup上每晚进行磁带或数据域增量备份。 原因是快照不能可靠地维护保留策略。 如果您告诉用户,他们将能够从一个星期的每日粒度备份一个月,而每个星期的粒度为一个月,则无法使用快照保留该承诺。
在具有快照的Netapp卷上,快照中包含的已删除数据占用“快速预留”空间。 如果卷未满并且已经以这种方式进行了configuration,则还可以推送该快照保留,并获得占用一些未使用的数据空间的快照。 但是,如果卷填满了,所有的快照,但保留空间中的数据所支持的快照都将被删除。 删除快照仅由可用的快照空间确定,如果需要删除保留策略所需的快照,则快照将会删除。
考虑这种情况:
此时,您的快照保留已被完全使用,因为您已允许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理框架,即使它像更新日志一样简单。 快照是一个非常棒的工具,但是我可以过度依赖这些工具来遏制重要的基本面。