备份已死……备份永生！

完成使命

对于基本问题的解决方案就是：保存整个应用系统在特定及时点“point-in-time”的状态以及提供从单个数据对象到整个系统的及时恢复。这种传统问题的解决方案一般可以分为三种：

新兴解决方案改进了现有备份的方法。其中包括：虚拟磁带产品、D2D2T（Disk-to-Disk-to-Tape）的备份方法，还有就是来自文件系统或卷快照的备份。它们都属于新兴方案。其中一项非常有趣的改进就是增加应用认知（Application Awareness）技术，它使得备份工具拥有了能够发现甚至控制应用所处状态的能力。因此备份功能就可以保存应用的已知及时点镜像了。同时，这个过程还需要使用应用所提供的APIs（ 应用程序接口）。一些主要的数据库和应用程序包（例如Oracle 和 SAP的）都与存储工具一直保持着紧密的合作。但是它们的作用只限于备份那些和它们有关联的应用。而对于其它那些不光包含有与它们关联的应用的系统来说，与它们的合作就显得不那么容易了。其他的工具如Dantz的 Retrospect, Veritas的NetBackup和 BackupExec, Legato的 NetWorker等等都是针对整个系统而进行的备份，而被它们所“认知”的应用和数据库包括：Lotus Notes/Domino、 Microsoft Exchange、Oracle (DBMS 和/或 applications),、SAP R/3等。

基本解决方案使用的是完全不同的技术来为数据的提供额外的拷贝。其中的一些主要技术如下：

1、镜像（Mirror，也叫做RAID 1）为磁盘卷提供了一个块到块（block-for-block）的复制。原始磁盘的镜像卷一旦完成，往后磁盘上的所有写操作都将在原始磁盘和镜像拷贝（在某些情况下镜像拷贝不只一个）上同时进行。镜像得以“同步”完成的前提是原始驱动器和镜像拷贝驱动器都必须要保证在一个写操作完成前，后面的写操作必须等待。虽然这样做会降低应用性能，但是保证了彼此间卷镜像的准确同步。而与之相对的就是非同步镜像。在这种情况中，原始驱动器和镜像拷贝之间的写操作不必保持同步，它们各自相对保持完全独立。因此，从应用的角度来讲非同步镜像要快于同步镜像。但同时，在任何一个规定的及时点上，非同步镜像都有可能发生其他镜像拷贝与主镜像拷贝不同步的情况。实践中，在一个数据中心内部，原始卷的写操作完成后，其对应的镜像拷贝过程很少会超过一分钟。此外，这两种技术都可以应用在异地远程领域，但是对于同步镜像而言，距离越远，它的性能就越低。

镜像经常被使用在很多关键性的应用上，并且为数据恢复的实现提供了一种最快的实现方式。如果需要恢复应用，只需使用镜像拷贝来代替原始磁盘，并且整个过程在瞬间即可自动完成。但是，镜像只有整个的卷才能被恢复。就是说单独的文件不能被有选择的恢复，除非一组镜像在之前就已经被“分开”，并且这之后所有写操作的拷贝也将不再添加到已形成镜像拷贝中去，而是在镜像组被“分开”的同时形成一个原始系统（镜像对象）的镜像文件。只有在这种情况下，才可能恢复某些选定的文件。镜像的另一个缺点是每一个镜像磁盘的容量都必须要不小于原始驱动器的容量，而不管真正需要使用的容量到底多大。

主要的镜像产品有：EMC的 SRDF 和 MirrorView； Hewlett-Packard的StorageWorks Data Replication Manager； Hitachi的ShadowImage；以及IBM的PPRC，它们都是优秀镜像软件的代表。此外，大多数RAID自身都内置有内部磁盘间的镜像功能。

2、快照（Snapshot）：就是在一瞬间即可生成一个磁盘卷或文件系统的拷贝。快照使用了一种叫做写入拷贝（copy-on-write）的技术，即在一个及时点（Point in time）上的快照完成了以后，任何新写入的数据（包括现有数据块的升级）都不会覆盖现有的数据，而是转存到另外的位置上，以保证原始数据的完整性。那些生成快照的软件或硬件都将对那些最初的原始快照中的数据块的情况进行跟踪，这其中也包括那些“活动的卷”。每个快照都可以进行单独的装载。在它完成装载的一瞬间，即可为应用提供对所需卷的访问。有些产品也允许对快照所生成的内容进行修改（新的写入或升级）。

如果快照对象没有被过大规模地修改过，那么多次的快照也只是会多占用非常小的存储空间。仅仅通过使用快照，就能够把整个卷恢复到以前的某个及时点的状态。并且同时还可以把这个卷重新定义为“活动卷”，进行继续跟踪。不过前提是所使用软件或应用必须支持这种特性。快照恢复数据有两种形式，一种是直接用最近的快照内容对快照对象进行替换，另一种是装载快照拷贝并手动转移所需文件。任何做了快照的及时点上的单个文件都可以被有选择地单独恢复。在底层，快照对象较以前的改动越大，新产生的快照所占的存储空间就越大。对装载后的快照进行访问会直接降低应用的性能，这是因为装载后的快照要与快照对象共同使用原来只是分配给快照对象的存储设备。另外，对于那些都将使用到同一个卷的各种应用来说，卷上所有的数据都处于同一个状态。每当考虑到这个情况时，我们通常就没有方法确定一个特定的快照能否完全反映一个及时点内的所有信息。

代表性的快照产品有：BakBone的 NetVault；CommVault的 Quick Recovery；Computer Associates的 BrightStor High Availability Manager； EMC的SnapView 和 TimeFinder； FalconStor的 IPStor Snapshot Copy； 以及 Network Appliance的 SnapRestore 。

3、复制（Replication）：不光只能为一个或一组相关的文件，还可以为整个文件系统或数据库，保存一份完美的拷贝。 与RAID1相类似，复制也是通过使用应用认知（Application Awareness）来为某个应用的详细数据保存完美的拷贝的。这点的实现可能是应用或数据库本身的特性，但同时也可能是通过应用的APIs（ 应用程序接口）来实现的。例如DB2、Oracle、 SQL Server以及其他数据库都拥有自己的复制方法，各种应用亦然如此，例如Microsoft Exchange 和 Lotus Domino。

数据库复制拥有很明显的优势，即能够保持所复制的数据的读取一致性（Read Consistency）。这是因为在整个过程中，复制拷贝都会以实时或者分批的方式，针对主数据库（即复制对象）的更改，来调整自己与之同步的过程。主数据库与复制拷贝数据库可以使用不同版本的DBMS软件或操作系统。并且我们还可以有选择地恢复某个单独的资料表(table)，甚至是单独的record。但是，在复制拷贝中，我们只恢复所需数据资料的最新版本。

通过使用日志，任何一个卷、数据库或文件的所有写和update操作都会在一个分离的区域、文件或设备上得到完整的记录。一份日志并不是一个对原始系统的拷贝，而是一份连续的关于写操作的历史记录。日志将向每个已记录的项中添加新的信息，其中包括在写操作中所涉及数据的原始位置以及写操作发生的时间和所涉及的内容。通常情况下，以上过程都是非同步完成的。与镜像和复制那种必须忠实地记录原始卷上任何数据所发生的所有的改变不同，一个做了日志的卷，甚至只是一个做了日志的文件都能够在数据尚未发生改变之前“回滚”（Rolled Back）到以前的某个及时点。但是，像快照这种在没有进行应用认知的情况下，在任何一个给定的及时点上，系统都有可能无法获得某个应用在一贯状态下的数据。

在典型的商业环境中，写操作大约占了全部I/O应用的20%。因此，随着时间的流逝，日志将会占用更多的存储容量。一般情况下，日志总是与镜像和复制一起混合使用，以便作为一种完整的卷、数据库或应用的灾难恢复方案。某些中立性的解决方案是无法深入了解应用和操作系统具体情况，如StorageTek的 EchoView 和 Vyant的 RealTime。

混合解决方案融合了以上的这些方法。例如将来自快照的所有文件都重新写入磁带介质——这样既提供了及时点拷贝，又消除了备份窗口问题。有些产品，例如XOsoft的Data Rewinder，就把应用认知与文件系统日志（File-System Journaling）结合到了一起，为每个应用的状况以及与这个应用相关的数据都提供了Known-good 快照。

EMC计划推出一个混合的解决方案，就是将VMware的虚拟机快照技术与自己的数据保护产品相结合。最终目的是将整个服务器以及其上面所运行的各种应用都简单地看成是另外的一些数据来并加以保护。例如，在同一时刻可能有多个卷快照发生，这其中也包含一个VMware 快照。而就在这多个卷快照同时发生的时候，一个应用也正好进行到了一半。在这种情况下，虚拟机快照就会自动暂停，等那个进程完全结束后再继续刚才的任务。这样就解决了所谓的应用认知问题。据悉，目前Veritas也计划通过使用自己的Ejasent产品来获得类似的解决方案。

建议与忠告

我们永远无法找到一种能够“包治百病”的解决方案。但是，还是可以找到一些任何组织的备份策略都应该遵守的共同原则。