【专家问答第二期】：不同存储集状态下Networker文件系统存储集的恢复（已结束）

恢复索引有两种方法：

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

2. 一种是nsrck -L7从备份介质中将index存储集恢复到Networker server的index目录中，此种方法只与存放index的介质相关。

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

如何在不同的存储集状态下恢复NetWorker文件系统存储集

不知道这个标题是否有点拗口？

请教：

1.当NW的某个Saveset处于Suspect状态,能否恢复此数据?

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

一样的.

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

1.当NW的某个Saveset处于Suspect状态,能否恢复此数据?

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

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

  不需要修改能够直接恢复的

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

不同的存储集状态 --> 你到底想问的事在哪个状态下的恢复阿？问题具体些吧
如果要看完整版本的"各种状态下的恢复"，建议参考networker admin guide

这是因为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命令还原在线索引，然后再进行数据恢复操作。如果磁带已经被重新标签，那数据已经被删除无法进行恢复了。

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

呵呵，只要是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. 如果要说best practise，那肯定是在对环境做任何改动前，至少将你的res和mm做一个备份，改动后要做备份恢复测试，不仅是针对改动后的数据做备份和恢复测试，同样也要对改动前的备份数据，做恢复测试。有问题及时拨打800电话开case。

专家回答的真好。鼓掌~~

对于第2点：

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

专家能否举例说明得更详细些？

机器名更换，ip变更，或机器迁移会造成clientid的问题？

clientid问题又是什么问题呢？

真要有这种问题又该如何解决呢？

Great

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

简单点说的话，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的问题，都是我们诊断出来。主要还是建议客户以防范为主。

Meg Li 编写: 这是因为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命令还原在线索引，然后再进行数据恢复操作。如果磁带已经被重新标签，那数据已经被删除无法进行恢复了。

专家你好，我们有用NW模块备份exchange和sql的。恢复的时候是否和文件系统存储集一样？我的意思是对于已经过了browse policy和retention policy的exchange和sql存储集是否也用以上方法？