【微信群提问分享】EMC的Networker跨平台迁移手册，原理是不是有问题的

多谢你把问题又重新描述了一次。我们会把这个问题反映给相关部门，看看有无对策。

感谢帮忙

en，Jason已经把建议提交到技术支持团队去了。谢谢 Li Wei

感谢Leo Li帮忙分享讨论

这个问题我当时表述不正确，正确表述如下：

———————————————————————————————————————————————————————

因为Target上只要起了Networker server进程，它就会给target固定cilentID，一旦target的clientID固定了，

之后的media database导入就无法将Target的clientID更改为原来的Source的clientID，所以只要是原来source上备份的存储集，

迁移后在Taeget上都无法恢复。

———————————————————————————————————————————————————————

关于此问题具体分析如下：

———————————————————————————————————————————————————————

EMC的Networker跨平台迁移手册中，在Target导入media database来达到恢复Source端mm信息这个操作是有问题的。

按照官方迁移的依据是：Target上启动Networker服务（因为导入media database数据需要nsrmmdbd进程），然后导入mm数据，

这样原来在Source上的所有mm信息就都复制过来了。

但这个做法忽略了一个关键点，就是Target在启动Networker服务时，由于此时的Networker备份系统中是没有Target自身client配置的，

所以启动Networker时会给Target自动创建client资源，重新分配clientid。

由于Target是Networker Server，所以后续的导入media database数据，无法修改Target的clientid的。

【关于此操作问题，我已经测试过，问题确实存在。

   这个问题，是可以克服的，并且可以保证所有mm信息完整、正确的导入到Target上。】

由于Networker Server的clientid发生变化，迁移后的潜在影响是多么危险可想而知。

———————————————————————————————————————————————————————

这个问题怎么克服呢

看EMC的技术团队怎么解决吧，我的那个是非常规操作，虽然合乎Networker原理，但毕竟是“歪路子”

我们按照SolVe生成的步骤做没有问题。在执行mmrecov之前，target系统上的client resource for Networker server是新的clientID。 在执行mmrecov之后，resource database被恢复到target系统。这之后，target系统上的client resource for Networker server拥有和source系统一样的clientID.  不清楚你具体在哪一步遇到问题？

Hi AndrewX,

    此前我按照的是Support中心Networker Docs里的跨平台迁移手册操作，在Target上执行nsrmmdbasm恢复mm之后，Target的client resource依然保持新的ClientID，不会更新为Source的ClientID。

    此问题会在Networker非同源操作系统间迁移时发生，如Windows迁移至RHEL，HP-UX迁移至RHEL。

    稍后有空，我查看Solve生成的迁移步骤是否和Networker Docs中跨平台迁移步骤一致。Thx.

抱歉，我没有仔细读你的问题描述。我们做的是同platform的migration。我试了一下SolVe，它好像只提供同平台迁移的步骤。你可以再试一下。我的理解是先恢复resource database然后恢复media database。另外应该确保source和target上hosts file的内容是相同的。

这个提问也挂了很久了，现在就自问自答了吧。。。

以下所有均是个人尝试得出的经验，非标准答案，也非官方认可的做法。

若借鉴，操作请慎重。误操出现的数据丢失，本人一概甩锅。

Networker跨平台迁移中，如果是同操作系统迁移，比如类似Windows 2008 迁移至 Windows 2012上，不会出现我所描述的问题。若是类似HP-UX往RHEL上这样跨平台迁移，肯定！肯定！肯定会出现我所说的问题。

目前在官方给出的所有文档上，没有发现任何关于此问题的Notes或者Solutions，这类边缘化的问题起码最近一段时间也不会被非常重视，因此我把我的解决思路写出来，若以后有人遇到，可以参考一下。

问题的原因（个人理解，正确性未知）：

之所以出现这个问题，还是在media database导入操作的时候，Target端需要启动Networker 。启动Networker 时，系统就会自动、随机给client分配资源，如clientid。这样一来，Source的clientid自然发生变化。

解决思路：

既然出现问题的根本原因知道啦，只要顺着这个就好解决了。

如果在新的备份系统里target 不是Networker Server了呢，target只是作为一台基本的client，那么media database导入导出的时候自然也不会发生上述的问题了。

所以……我的解决方法是media database在target端导入的时候，target的hostname不是原source的hostname，这样就避免了target的media database信息不会和原来的不一致，完全导入。

具体做法：

思路都有了，具体做法还不开动脑筋想！！

解决方法的合理性：

1，按照networker原理分析，当target只是一台client时，media database的导入操作成功，合情合理。

2，media database的问题解决了，当source hostname和target一致、作为Networker Server的时候，保留已导入的media database，再删除非res、mm（index如果是直接复制过来的话，也要保留）其他所有目录让Networker重建备份系统的信息。因此新备份系统，基本的media database，res，index都是原备份系统完整迁移过来的，其他配置也是Networker Server自动创建，木有问题。

太好了对于我的问题非常有帮助 再顶下