Bootstrap详解以及灾备恢复时如何正确定位Bootstrap

Bootstrap详解以及灾备恢复时如何正确定位Bootstrap发贴人EMC备份恢复远程支持部在备份和恢复系统开启2013-9-2619:37:00很多人对于NetWorker的bootstrap并不十分了解，或者并不会特别清楚NetWorker的bootstrap的备份和恢复原理。但是其实作为一名备份管理人员，我们应该认识到的是bootstrap不仅仅是NetWorker的重要部分，而且可以算为NetWorker的精神领袖和灵魂。只有备份服务器的bootstrap还物理存在，那么无论是遭遇硬盘故障，还是机器瘫痪，或者是人为删除了控制文件，我们都可以通过恢复最新的bootstrap来重建我们的备份服务器。听上去很神秘，看上去很复杂。但是其实只要我们了解到bootstrap的组成和备份恢复方法，实际操作起来还是非常简单的。下面就让我们来了解一下bootstrap的组成以及恢复时如何及时且正确的找到需要的bootstrap吧。说到bootstrap不能不先提到NetWorker的控制数据。NetWorker的控制数据是NetWorker备份服务器上存储的NetWorker配置信息和备份跟踪信息的统称。NetWorker的控制数据包含三个组件：资源目录：该目录包含资源文件。NetWorker会以资源的形式存储和维护配置信息。资源信息存储在/nsr/res目录下的资源文件中。包含的资源文件目录包括：Nsrdb-此目录下的文件包含描述客户端，设备，磁带库，备份开始时间，备份计划以及许可证等事项的配置信息。此目录仅仅存在于NetWorker备份服务器上Nsrladb-此目录下的文件所包含的资源信息用来确定该主机在接受其他NetWorker主机的连接以及连接到其他NetWorker主机时所用的RPC端口范围。所有的NetWorker主机都使用此目录。Jobsdb-此目录包含由各种操作（如备份）生成的统计数据和信息，供NMC用于创建报告。介质数据库：该数据库用于跟踪NetWorker使用的所有的卷和写入到这些卷中的所有存储集。客户端文件索引（CFI）:这些数据库可以跟踪客户端备份的每个文件（路径名），从而允许用户浏览特定时间点的文件备份。这个信息对于NetWorker而言十分重要，但是在本文中不会涉及。有兴趣的读者可以阅读NetWorker管理员手册了解到更多关于Index的信息。我们经常提及的bootstrap其实简单而言就是备份的/nsr/res和/nsr/mm的存储集，简而言之就是备份服务器的配置信息和介质数据库。由于很多客户对于这个名词并没有直观的了解，导致并没有重视bootstrap的备份和追踪，这在很大程度上会影响到灾备恢复的及时性。如果bootstrap就是备份服务器的灵魂信息，是NetWorker重建的必须数据，那么NetWorker是通过什么机制去实现定时备份呢？是否需要人为去触发备份呢？这种备份和普通数据备份或者模块备份相比又有什么不同呢？由于bootstrap存储集的特殊性，NetWorker并不需要客户手动定义去实现备份，而是通过自己的备份机制去实现即时的备份。对于bootstrap这个特殊的存储集，NetWorker是十分重视的。Bootstrap永远只有全备，目的很容易理解，方便我们恢复的时候可以更快的得到需要的数据。而且bootstrap的存储集是NetWorker服务器自行产生的，这样就可以完全避免由于人为失误造成的数据缺失。在下面三种情况下可以实现bootstrap的备份：1.1.如果客户创建的某一个备份组里面包含备份服务器，那么在该组发起备份的时候备份服务器就会产生bootstrap存储集进行备份。2.2.如果备份服务器不属于任何一个备份组，那么每24小时内，boostrap存储集会在组备份发起的时候产生一次，进行一次唯一的备份。这样就可以避免备份数据重复浪费备份介质和网络带宽。3.3.如果基于某种原因需要手动备份bootstrap，可以运行命令savegrp–O–Ggroup_name前面我们介绍了bootstrap的实际内容和的重要性，下一步需要了解的就是如何以最快最精确的方式找到bootstrap。这样在灾难恢复的时候我们才能最快的重建我们的备份服务器，也就是整个备份环境的核心和灵魂。Bootstrap的备份信息保存在boostrap报告中。对于最近40天内的备份数据，bootstrap报告里面都列举了详细的SSID,保存的卷信息，以及文件信息等。这个报告可以大大加速恢复时定位bootstrap的时间。既然这个报告如此重要，那么作为备份的管理人员，一定需要非常认真负责地管理。我们NetWorker管理控制台提供了一个发送bootstrap报告的时间，默认的截图如下：在这里备份管理员可以设置将bootstrap报告发送给备份管理员或者其他管理人员。这样在灾难恢复的时候，可以在邮件里面定位需要使用到的bootstrap信息。如果不进行正确的配置，那么bootstrap报告就会丢失。下面图示列举了bootstrap报告的具体信息：如果我们的备份管理员并没有正确配置bootstrap报告，或者没有保存bootstrap报告，那么如果需要特殊情况我们需要恢复bootstrap，那么我们的工作量就会巨大，并且有时候会无从下手。但是这种情况却往往发生，一旦出现情况，再去补救已经晚了。那么此时我们就只能想法设法地找到我们需要的bootstrap存储集所在的卷，然后再定义出我们需要的bootstrap的相关信息。一般来说有下面一些方法我们可以去尝试：1.1．在Savegroupcompletionreport里面去找到最近的bootstrap的相关信息。对于windows而言，这个报告默认保存在……\nsr\logs\savegrp.log中。对于UNIX而言，这个报告会通过邮件的方式发送给根用户。2．我们可以尝试去寻找备份服务器上的最近的daemon.raw文件。3．说到这里大家可能会发现，上面所提到的文件都是保存在备份服务器上的信息。而一旦在重建备份服务器的时候，往往我们连这些信息都是没有办法查询到的。往往到了这个时候我们就只能使用scanner的绝招了。一般来说，这需要备份管理员回忆最近使用到的备份介质，当找到介质的时候再把介质载入NetWorker。然后通过scanner–B的命令来通读整个卷从而找到最近的bootstrap备份。Scanner命令是NetWorker的最后也是最傻的一步，就是读整盘磁带，然后找到或者重建自己所需要的信息。可想而知，如果磁带容量大，或者数据比较繁杂，命令的运行时间是很长的，这往往成为了灾难恢复中最耗废时间和精力的地方，但其实也是可以通过很多预防机制避免的危险。具体的恢复方法和命令操作指南，可以参考对应版本的灾备恢复手册，里面有详尽的介绍，这里就不再赘述。介绍了那么多信息，是希望读者可以从本质上面了解到bootstrap并且知道如何去管理它。虽然说平时我们使用到它的机会并不多，但是往往在重大的数据恢复关头，bootstrap的恢复会成为整个过程成功与否的关键。如果作为备份管理员可以了解到bootstrap的重要性和管理的可行性，那么在出现问题的时候，我们可以处理得更加游刃有余。数据的丢失也可以尽可能地降到最低。也最终体现了我们NetWorker产品备份数据的可靠性。s