15.4.3.8 数据备份/恢复，归档，和容灾
Snapshot 技术从根本上改变了对数据的备份/恢复、归档的操作方式。
备份数据可以保护由于用户误操作或者硬件故障造成数据丢失，对数据归档(archiving data )可以生成完整的具有一致性的数据集合的副本，用于将数据恢复在线到将来的某一个时间。备份保护免于故障，归档可以使业务暂停并恢复工作(可以在另外的地点)。
从backup 的数据中经常会只需恢复某个文件或某个目录，而不必进行整个文件系统的恢复。 而归档archive 往往要完整地进行恢复。容灾 Disaster recovery (DR) 和备份和归档的特点类似，用于防止故障，更强调灾害、整个建筑灾难的情况。类似归档，DR 的数据必须具有一致性，使作业可以在容灾点继续。
对数据备份可以包括对项目的归档，在另一地的项目归档可以用于从灾难恢复。
备份和归档最重要的问题是速度。当把大量数据备份到磁带或者其他的介质时，由于数据量很大，备份本身就对系统产生了很大的工作负荷，使得系统性能下降，备份必须尽快完成以避免对用户产生影响。所以备份工作一般在下班时间，对于24×7 的环境，则没有下班时间，“BACKUP WINDOW”越来越小。
对备份速度的主要限制是由于磁带机的速度，现代磁带机的速度一般每秒几兆字节，几百GB 的数据就需要多台高速磁带机并行处理。数据的一致性是另一个问题，为防止正在备份的文件被修改，简单的备份程序会锁定文件处于不可写状态，而这只能通过offline或single user mode 进行。
备份程序虽然试图解决在线备份的问题，但是用户仍然面临数据完整和一致性的问题，备份无法保证是可以恢复的。
NetApp 的Snapshot， SnapMirror 和 SnapRestore™提供给系统管理员有力的解决这些问题的工具。
常常因为用户错误而进行恢复，用户经常意外删除、覆盖或其他方式修改了不该改的文件，对于DBA 和SAPDBA，这样的机会特别容易发生。现代系统往往提供了很大的硬件保护，时数据在硬件意外时不丢失。
Snapshot 为用户提供了自己恢复错误的能力，不需要依靠系统管理员从磁带定位，恢复自己的文件。
Snapshot 是当前文件系统的一个只读的、一致的副本，提供了巧妙的解决在线备份的解决方案。在进行备份前，对文件系统拍快照，快照只需一两秒就完成。然后把最新的Snapshot 目录中的数据备份。由于快照目录下的数据只读，永远不会被改变，所以可以保证备份到磁带的数据的一致性，这样磁带备份的速度不会影响数据一致性，因为对当前文件系统的改变不会影响到快照的数据。用户当前的文件系统总是可以读写的，用户的作业不受影响，而备份设备看到在备份前即时做的快照，它稳定不变。
这种随时(在线)生成具有数据一致性的、可以恢复的档案的能力，具有无比重要的价值。
Snapshot 提供了特别方便的方法对关系型数据库文件( 包括DBM 文件、email/messaging 数据库，如Exchange 和Notes，动态WEB 页面内容数据库，不仅是传统的RDBM，像Oracle， Sybase， SQLServer 等)。
传统的方式在备份前保证数据一致性的方法是关闭控制数据库的应用程序。备份过程往往包括，关闭应用程序，进行备份，重启应用程序，停机时间完全取决于备份的速度，从几分钟到几个小时。进行热备份需要将应用程序、数据库转换为热后备模式，备份完成后再转换回正常运行模式，热后备模式影响系统的性能，需要尽量缩短热后备时间。
利用Snapshot 可以把停机时间缩短到几秒种—-生成Snapshot 的时间。操作方式：停应用，拍照，重起应用，把在Snapshot 目录里的内容倒到备份介质，这种备份的数据/归档具有数据一致性的保证，确保应用程序可以立刻使用。
同样重要的一点，这些快照可以保存在线存在很长时间，万一数据库毁坏就可以立刻用来恢复，极大地减少了恢复时间。
磁带设备的速度比较慢，系统的吞吐量执行tar/dump/pkzip 类型的工具只有几百KB/s，硬盘相对快很多，所以在数据中心数据临时dump 到磁盘设备，然后再下带。随着磁盘的降价和性能提高，这种方法越来越流行。
Network Appliance 的 VolCopy 功能提供给用户将数据高速整卷迁移到另一台Filer的方法，速度达到~45 GB/hour。使用VolCopy，用户可以在另一台机器FILER 上生成一个完全一样的文件系统，包括原数据系统的所有Snapshot。复制时目标系统不可用，一旦复制完成目标系统的数据就可在线。VolCopy 提供了一种快速将数据从一个卷迁移到新的位置的方法，可用于升级到新的系统，或者生成一个副本，副本的数据进行磁带备份而不管源数据正在发生变化，或者用于容灾。
Data ONTAP（Filer 的操作系统）利用WAFL Snapshot 功能提供了自动的文件系统级的复制功能：SnapMirror。通过SnapMirror 技术，一个源filer 可以将一个或多个文件系统复制到伙伴Filer，使伙伴Filer 上的文件系统与源Filer 的自动生成的Snapshot 同步。伙伴Filer 可以分布在任何地方，可以在同一大楼或者地球的另一边，只要源和目的之间有网络连接和复之数据需要的带宽。
SnapMirror 在WAFL 里的对block 进行操作，效率很高。文件系统是由磁盘中的块组成的，Snapshot 文件系统一个固化的版本，表示文件系统拍照时的状态。
WAFL 利用内部的块映射表（block map file）记录了哪些块属于哪些不同的Snapshot，block map file 记录每个BLOCK 是否属于当前文件系统或是某个快照。 如下表，BLOCK 28854的数据在Active File System 和Snapshot 1 中，而snapshot2，3，…20 都没有用这块。
WAFL block map file 使得SnapMirror 很容易确定两个Snapshot 的数据变化（增量），例如上表， block 28856 不在Snapshot 1， 却在Snapshot 2。.假如Snapshot 2 在Snapshot 1 之后拍的， block 28856 一定Snapshot 1 拍完后假如到Snapshot2 的，而 block 28854在Snapshot 1 里，但Snapshot 2 里没有，所以是Snapshot 1 拍完后删除的。通过比较两个快照的不同， SnapMirror 可以十分有效地顺序将变化数据复制到另一台设备。
SnapMirror 复制开始时，目标Filer 安排源Filer 拍快照”Snap A”，建立与源Filer的TCP 连接，开始传输”Snap A” 文件系统的块。
数据传输完成后，目的Filer 上的数据十完整的、具有一致性保证的，而且完全等于”Snap A” 文件系统，包括与SnapMirror 无关的“Snap A”快照时的SnapShot 的信息。目标Filer 上的数据可以被用户只读访问。当“Snap A”传输时，源Filer 上的数据也正在发生变化，然而 WAFL 的 copy-on-write 策略保证了所有变化数据在传输期间写入到新的“Snap A”以外的block。
为了保证目标Filer 自动复制源Filer，变化的块也要传往目标Filer。目标filer 安排源filer 进行另一个Snapshot，”Snap B”，然后建立另一条TCP 连接传输两次快照期间变化的数据。
当目标Filer 接受完成SnapB，其数据是具有数据一致性且等于源Filer 的SnapB，SnapA会被删除，新一轮传输又再启动。
SnapMirror 通过在目标Filer 上的一个简单的配置文件控制， /etc/snapmirror.conf， 设定Snapshot 的发生间隔和数据传输的时间。 该文件包含下列格式的命令行：
srcfiler:srcvol dstfiler:dstvol schedule
srcfiler， srcvol， dstfiler 和dstvol 分别代表source filer， source volume，destination filer， 和destination volume 的名称。管理员利用后面的变量值控制复制传输的特性。例如throttle value，阈值，限制Filer 间的数据传输最高带宽kilobytes per second。
Schedule 参数由4 个独立变量组成，minutes，hours，days of the month，和days of the week，表示传输发生的时间。
例如， /etc/snapmirror.conf 如下的一项：
sf:sv df:dv 2000 30 8，12，16，20 * 1，2，3，4，5
将使得目标volume 在 8:30am， 12:30pm， 4:30pm 和8:30pm， 每周一到周五，进行同步，阈值是2000 KB/S 或2 Megabytes/Second，两台filer 间的最大数据传输带宽。*表示所有的月。
srcfiler:srcvol dstfiler:dstvol – * * * *
指示目标卷尽快与源卷同步，-表示以网络允许的最大带宽传输。
在源Filer 上的配置文件/etc/snapmirror ，控制只有指定的Filer 才可以进行复制。提供复制的安全性。
