省某平台交易中心IBM 1814 DS5020光纤存储恢复

  返回  

枣庄矿业DELL存储Esxi虚拟化数据恢复

枣庄矿业DELL存储Esxi虚拟化数据恢复

枣庄矿业DELL存储Esxi虚拟化数据恢复

服务内容:

上门时间:2015-10-26 10点接到通知
结束时间:2015-10-27 20:34回到济南西站
事项:数据恢复客户的DELL3200的数据,已经发给客户,客户自己不会添加到ESXI中,要求我们上门协助解决.


  周一上午到了枣矿,做Esxi虚拟化系统集成的工程师已经在调试了,(原来济南煤炭局数据恢复一块合作过,所以比较熟悉)发现他的安装存储的管理软件,还没连上存储,我们这里有,打开电脑,他应该是想知道存储的iscsi口地址,看了下,告诉他这个我们在调试的时候应该改过了,最好能找到原来的IP,再改回去。
工程师把原来配置的存储上的各网口地址告诉我们,我们就按他说的配置了一遍。工程师重新扫描了一下,发现原来的那些虚拟机并没有找到,得再添加一下存储。
他担心添加的时候会把原来的数据删除 ,我们告诉系统 会识别到之前 的格式,直接添加上就可以了。他试了一下,添加上几个iscsi存储,但是还是发现不了原来的虚拟机。
主管这时候告诉他下面的一个李姓工程师,要求下面的存储重新配置一下RAID,跟下面的几台机器重新组成一个虚拟化系统 。李工说好,然后要求我们教他怎么配置这个存储。
我们就把从安装软件起到配置RAID,及做热备的方法教了他一遍,并现场把下面没数据的存储按他的要求做个RAID5,并且其中一块盘做成了全局热备进行了配置,(期间遇到几个存储的问题,一个是无法打开iscsi的网口配置界面,于是又让李工找了个交换机把两个控制 器都连接上;由此看来这个存储其实控制器是有点问题的)
这时候客户发现了一个问题,说上面的配置的虚拟机在重启了之后ISCSI会自动断开,三台机器 都是这样,还有两台机器 无法连接存储上的LUN,一添加就提示让格式化。
我们这时候看了一下机柜上的机器,上面总共有五台R710,全是装的ESXI4.1,通过交换机连接到我们找回数据的这个存储的上控制器的前2个网口,下面还有2台NF500D2,通过网口直连的方式连着刚才我新配置的没有数据的存储,连的是存储的下面的控制器1号和2号网口,当然 还没连上,因为 还没有做映射 ,刚才说的是物理的连接。
我们跟着主管把服务器全都停掉,存储全都断了电,等了十几分钟之后先启动存储,再启动服务器,发现iscsi连接可以自动建立 ,但是不能自动添加存储,虚拟机当然 也无法找到。
徐总说我们找回数据 的存储上有些数据校验不过去,是有问题的,不要在生产环境上用,需要的话就把数据 拷出来 。于是我给客户说了这种情况,要求用刚才新做RAID的存储当作一个中转介质,把里面的虚拟机文件拷出来,在另外一台存储上当作 生产环境。客户同意了这种作法,于是和工程师商量了一下,决定把所有的设备都通过机柜上面的交换机进行连接,这样一来拷贝数据 的时候快,二来配置起来也方便。于是找了几根网线,把设备都接到了交换机上。
存储上的数据 量非常大,如果全拷的话肯定 不可行,客户说,那就捡着重要的先拷。
工程师在下面的两台NF500D2上部署了一个虚拟机管理中心,把所有的ESXI都放到这个管理中心里,这样就可以直接在这台机器上对所有的机器 进行部署了。
两边存储都连上之后工程师使用虚拟机迁移工具进行迁移,我们给他说最好使用复制的方法,他似乎没用过文件夹复制 的方法,我们告诉他怎么操作之后他也觉得使用复制 更安全一点。
第二天到了现场,昨天晚上部署的任务多数都完成了,还有几个在拷,有两个失败了的,应该是部署的任务太多,等这些结束了之后再接着拷就可以。
主管要求的最重要的两个虚拟机已经拷贝完成了,于是尝试着启动,第一台是微震的服务器,里面跑的centos7,装的是每天上传的一些报表 的数据 ,用的是LAMP,机器 启动了之后从另外 一台同网段的机器进行访问的时候,发现无法访问,于是主管打电话找原来程序 部署的工程师远程看一下,但是那个工程师现在在外面,无法直接操作。主管就向我们求助,我们帮着他找了一下,并通过电话向部署的工程师问了一此配置之后将本地的服务启动起来。
但是在同网段的另外 的机器 仍然无法访问。我通过数据库 查了一下,发现数据 有几百万条,那边 部署的工程师说这样的话应该数据 都在。别的机器 不能访问,我考虑了一下判断 是防火墙 的原因,于是就把机器 的防火墙 关掉。果然 ,外面的机器 就可以访问了。主管查了一下,数据 都正常。
第二台是一个WIN2003,信息科领导试着处理,说应该没什么问题。于是皆大欢喜。
客户希望我帮他们启动了一下,系统 可以启动应该可以证明数据 没有问题,数据库 启动不了要么是没有设置自动启动,要么是数据库 之前 就损坏了。于是我直接使用sysdba登录,并且尝试打开数据库 。但是发现数据库 可以挂载,但是找到的时候就报01595错误,查了一下判断 是undo表空间损坏,于是把当前 的oracle系统 启动到挂载阶段,并且把当前参数保存成pfile,然后修改参数 里的undo表空间的管理方式然后从pfile启动数据库,发现可以打开。
这时候把原来的undo表空间给删除,新建 了一下给了系统 。接着把原来的数据库的spfile删除 ,并且把当前的参数文件又生成了一份新的spfile。再重新启动数据库 ,发现数据库 可以正常打开。
此时已经是下午1点多,主管打电话让那边 的人查了一下数据,那边 说没有数据了!我一想,不应该啊,没有动数据库 ,只是改了一下表空间配置文件,怎么会没有了呢。于是主管要过用户名和密码登录了一下,发现真的没有数据 ,在几个页面点了一下,发现有的页面也报了错,是oracle的错,报的是01552, 发现是非系统 表不能使用系统 的表空间,通过讨论找到了解决方法,表空间的管理方式改成自动就可以了。
重要的机器 都启动了,客户要求恢复到生产状态,并且做一下重启测试。于是工程师把机柜的所有的线都插回到最初的样子,此时所有的虚拟机已经迁移 到了下面的NF500D2上,所以上面的机器 就不太重要了。去重启的时候发现最初有数据 的存储其中一块盘又坏了!我们都庆幸,数据 及时拷贝了出来 。
重启测试之后一切正常。

注:重要的数据一定要注意备份,同时加强设别的巡检与维护!


联系我们

济南鉴信DATAHELP服务器数据恢复中心
数据恢复服务热线:18615682298
数据恢复服务电话:0531-62399989
公司传真:0531-55575577
数据恢复业务Mail:DATAHELP@163.COM
数据恢复公司地址:济南市山大路157号华强电子世界三楼Q3059,Q3060