不同存储集状态下Networker文件系统存储集的恢复

介绍

本帖整理了“专家问答Networker不同存储集状态下文件系统存储集的恢复”的集中问答，内容包括备份的存储集有哪几种状态、如何恢复各种状态下的存储集，恢复索引的两种方法，恢复索引和数据时的问题处理，以及NetWorker用户在日常工作中的常见错误和恢复时的最佳实践等，助你深入理解NetWorker文件系统存储集的恢复。原问答贴链接：https://community.emc.com/thread/147823

更多信息

问题1：恢复文件系统存储集index的时候，如果数据存储集跨多盘磁带，需要手动加载磁带（nsrjb -u），扫描（scanner）完一盘后再手动加载另一盘并扫描吗？

回答：是的，如果存储集跨多盘磁带，需要手动加载磁带，扫描完一盘后加载另一盘。

使用scanner的情形是存储集已经过期时从磁带里遍历存储集数据重建index。

在使用scanner前我们可以先用mminfo命令找到此存储集的存储集相关信息：

mminfo -avot -q ssid=[ssid] -r “volume,sumflags”

此输出会列举出我们要恢复的存储集所在的volume信息以及存储集状态信息。如果存储集跨多个盘，volume会有多个，对应的sumflags标志位会显示hE （head，Expired），mE （middle，Expired），tE（tail，Expired），其中如果存储集只跨两个盘，那么mE这个标志位是没有的，只有hE和tE。

查询到以上信息后进行scanner操作：

1. 在未加载的情况下装入(load without mount)标志位为hE的磁带，此操作可以在NMC管理界面上进行，也可以通过nsrjb命令实现。

2. 执行scanner -i -S [ssid] [device name]；

3. 第一盘磁带扫描完成后，命令行界面上会出现提示，要你插入下一盘磁带，此时弹出第一盘磁带，装入标志位为mE的磁带，继续扫描；

4. 直到最后tE标志位的磁带也被装入扫描完，scanner命令会停止，此时一个完整的scanner命令执行完成，该存储集的index被重建回来。

问题2：关于第3步：“3. 第一盘磁带扫描完成后，命令行界面上会出现提示，要你插入下一盘磁带，此时弹出第一盘磁带，装入标志位为mE的磁带，继续扫描；”，是不是意味着提示插入下一盘磁带和弹出磁带都是带库自动操作的？我要做的只是按照提示手动插入下一盘磁带？插入下一盘磁带以后还要重新输入一遍scanner命令吗？

回答：执行scanner命令前，所有磁带都必须在带库中。不再需要你手动再插入磁带。

执行scanner命令时，一盘磁带扫描完提示下一盘磁带时你需要做的是在NMC管理界面“卸下”上一盘磁带，在未加载的情况下装入(load without mount)下一盘磁带。

不需要重新输入scanner命令，命令行界面会询问你是否继续扫描，下一盘磁带装入后，选择yes则scanner会继续进行。

问题3：最后一个写完的磁带，是否应该包含前一个磁带（同一个备份集）的index信息？

回答：scanner命令的本质是从备份的数据中“重新创建”新的index，并不是恢复已经备份的index信息。所以，如果存储集跨多盘磁带，每盘都需要去做scanner。如果是要恢复已备份的index，应该用nsrck -l7.

另外，index备份的位置一般和数据本身是分开的（根据服务器的设定来决定的），最后一个写完的磁带并不包含前一个磁带（同一个备份集）的index信息

问题4：如果索引备份的位置和数据本身不分开呢？重建索引的方法会有不同吗？

回答：恢复索引有两种方法：

1. 一种是scanner命令扫描数据盘重建索引，此种方法只与数据盘相关。

2. 一种是nsrck -L7从备份介质中将index存储集恢复到Networker server的index目录中，此种方法只与存放index的介质相关。如果存放index的介质没有了，只能用scanner命令来遍历存储集数据重建索引

二者没有联系也不冲突，所以索引备份的位置和数据是否分开存放，都不影响。关键只在于你选择哪种恢复索引的方式。

所谓的“不分开”，最多能够做到的就是数据和索引放到一个pool或者一盘磁带上，在save set层面肯定索引和数据是在两个不同的存储集的。

问题5：在未加载的情况下装入(load without mount)的作用是？load & mount完以后再scanner不可以吗？

回答：load & mount完以后再scanner也是可以的，但是mount操作本身有验证标签的过程。在有些要使用scanner的情况下，媒体库可能已经没有这盘磁带的相关信息了，包括标签，这个时候就无法mount上去，操作会失败。这种时候就必须使用 load without mount来避免验证标签的过程。所以通常情况下，要运行scanner命令前建议使用load without mount。

问题6：如果saveset处于Suspect状态,能否恢复此数据?

回答：可以尝试恢复但不保证一定能够成功。suspect状态表示networker怀疑这个备份集本身是存在问题的。一般看到这种状态建议及时再次进行备份。

问题7：如何从clone pool中恢复数据? 是否只能通过修改backup pool的save set状态,才能从clone pool的介质中恢复数据?

回答：不需要修改能够直接恢复的。但是最便捷的方法是将备份数据的盘设置成离线状态。这样恢复的时候networker会去找clone备份集进行恢复。

问题8：如何在不同的存储集状态下恢复NetWorker文件系统存储集?

回答：Networker备份的存储集可能会有多个状态，不同的状态采用的恢复方法不一样。

可浏览（Browsable）：

存储集还在browse policy设置的时间内，备份索引还在，可做索引恢复（index recovery）。

可恢复（Recoverable）：

存储集已经过了browse policy，但仍然在retention policy的时间内。此时在线备份索引已经被删除，可进行存储集恢复（saveset recovery），如果需要做索引恢复，需要使用nsrck -L7或者scanner先还原在线索引才能进行索引恢复。

可回收或已过期（Expired）：

存储集已经过了browse policy和retention policy，数据集已经过期，存储空间可被回收。

1. 如果备份集存放在AFTD类的磁盘介质中，存储集的索引和媒体库记录均会被删除，空间被回收清空以进行新的数据备份，数据不再能被还原回来。

2. 如果备份集存放在磁带类的介质中，在整盘磁带没有被重新标签（relabel）的情况下，虽然在线索引已经被删除，但媒体库关于这个存储集的媒体信息记录仍在，此时仍然可以进行数据恢复，但需要先将存储集的状态手动修改为和恢复状态，然后再使用nsrck -L7或scanner命令还原在线索引，然后再进行数据恢复操作。如果磁带已经被重新标签，那数据已经被删除无法进行恢复了。

问题9：我们用NetWorker模块备份exchange和sql。恢复的时候是否和文件系统存储集一样？对于已经过了browse policy和retention policy的exchange和sql存储集是否也可用和文件系统存储集一样的方法？

回答：对于恢复在线index文件，方法都一样。但是数据集的恢复根据模块会有不同。

问题10：请专家分享下做NetWorker恢复时通常需要注意的以及我们普通用户经常容易犯错的地方，以及专家们的心得体会和操作中的一些最佳实践。

回答：

1. 对于恢复来说，最重要的就是数据备份要是好用的。正常备份完成后的状态会是可浏览的，如果备份集状态显示不正常，应当及时联系EMC Networker support来排查问题。有的客户备份失败近一年然后才上case来问怎么回事的。那这近一年的数据，谁保证它的可恢复性？

2. 备份环境一般涉及到很多台机器，如果涉及到机器名更换，ip变更，或机器迁移，最好先行查看相应文档，或咨询再进行操作。再差一点，最起码要保证有可用的bootstrap和index的备份，或者手动将res和mm文件夹做个备份。我们工作过程中经常会遇到客户擅自更改客户机名字或更改机器域名，又未进行任何备份，导致clientid问题，使恢复难度加大的情况。

3. 设置合适的browse policy和retention policy。查看前面帖子里我提到的和大家所关心的重点，你会发现都是index相关的。index的保留策略就是通过browse policy的设置实现的。根据自身的业务需求，制定合适的数据保留策略，非常重要，这样可以保证你的磁盘磁带空间更充分利用，同时保证重要数据能够更快速恢复。关于恢复的case，我们遇到的很多都是数据已经过期了，需要再恢复回来继续使用。对于这样的数据我觉得客户可以考虑将数据的browse policy设置的稍微长点，因为索引恢复是最方便的一种恢复方式。

4. 如果要说最佳实践，那肯定是在对环境做任何改动前，至少将你的res和mm做一个备份，改动后要做备份恢复测试，不仅是针对改动后的数据做备份和恢复测试，同样也要对改动前的备份数据，做恢复测试。有问题及时拨打800电话开case。

问题11：对于第2点，专家能否举例说明得更详细些？机器名更换，ip变更，或机器迁移会造成clientid的问题？clientid有问题会造成什么问题呢？如何解决？

回答：这个问题要回答起来就是得看具体环境拿到具体输出来分析了，写成书面比较困难，很难说的精确。

简单点说的话，networker的每个client会有个clientid来与它对应，所有的备份索引其实是和clientid绑定的。如果客户机名字变更或者迁移，可能会导致生成新的clientid，那么可能侥幸我的备份能继续进行，但实际上已经是备份到新的clientid下面去了。这个时候想做旧clientid的备份集的恢复，会因为clientid已经不匹配，networker根本没法识别index。那么恢复就遇到困难了。

这个解决起来也是具体情况具体分析，得看要恢复的数据目前绑定的clientid是哪一个，目前使用的clientid是哪一个。常用的方法是要在hosts file里面建一个dummy ip 和dummy client。将新的clientid assign给dummy，将旧的clientid再assign给客户机资源，使它能再次识别以前的clientid下对应的index，做恢复。。。（具体怎么使用dummy，是根据客户的环境来定的，我所说出的也只是其中一种情况）

真要有这种情况，还是直接上case吧。一般客户根本没法自己意识到clientid的问题，都是工程师诊断出来的。主要还是建议客户以防范为主。

问题12：我在还原的时候networker user里面无法浏览到想要还原的文件和文件夹，只能做save set的还原。但是mminfo出来的结果显示该save set状态还是cb。请问是什么原因？

回答：在Networker server备份任务不多的时候运行下nsrck -L6做个index检查看看saveset状态是不是还是cb，查看下浏览策略设置的时间本来这个存储集应该是什么时候回收index；

还有就是要看Networker server或者客户机有没有做过什么更改，导致在线index被删除了。

问题13：在用scanner恢复index之前，是否需要先将index文件夹整个删除？

回答：做scanner之前不需要删除index文件夹。scanner重建的index只是往当前的index中加入，做一个合并，不会删除或影响当前index文件夹下的任何东西。

更多详细内容，请参考https://community.emc.com/thread/147823