IBM DS4700 存储硬盘故障数据恢复案例
技佳科技
客户服务器出故障以后，技术和IBM售后支持处理了两天，一直搞不定，毕竟raid5阵列如果掉两块盘，一块盘报警，一般是无法再恢复数据的，从网络上搜索查到技佳公司，客户是某东省建设局，运维着省建筑申批等系统，因运维的技术以前有和我们合作过，联系上了北京技佳瑞康科技有限公司深圳分公司的罗工上门恢复，厂家工程师也无法处理。需要上门配合进行紧急数据恢复处理。
驱车上门后，来到数据中心机房，和客户沟通清楚后
1、->故障检测前IBM DS 4700 光纤存储了解
IBM DS4700 全名(IBM System Storage DS4700 )是IBM推出的中端存储系统，它有一个设计合理、功能强大的内部架构，大幅度提升了性能，但某些物理故障或其他操作都可能会对卷或存储造成破坏，因此对系列存储的数据恢复技术才有了用武之地。
DS4700产品系列是包含4 Gbps光纤通道(FC)接口的存储服务器。DS4700 是IBM SAN解决方案的一部分，结合IBM SAN交换机技术。EXP810扩展柜支持SATA磁盘，可以最大支持112块SATA磁盘，裸数据容量可以高达56T。为用户提供低成本大容量的近线存储解决方案。最多支持1024个逻辑卷(LUNs)、可定义大于2T的阵列组。存储管理软件v9.16拥有FlashCopy?等高级存储管理功能。
Enhancement Remote Mirror(Global Copy和Metro Mirror)
增强的远程镜像包括Global Mirror, Global Copy和Metro Mirror，Metro Mirror用来将一个存储系统镜像到另一个存储
支持FlashCopy 和 VolumeCopy 备份方式
2、->存储故障检测分析
挂载12块硬盘，存储oracle 10G的好几个数据库，两块600G的硬盘报黄灯错误，掉线相隔时间为10分钟，在BIOS下查看阵列卡的信息，raid组成员offline 所以进入服务器后，显示卷无法挂载/业务中断，公司所有员业无法作业，需要进行加急数据恢复处理，而且多个系统，多个公共服务在上面，都放在此存储上
查看服务器存储当前状态，物理磁盘状态进行查看，发现10号磁盘状态为“alter警告”，6号硬盘和8号磁盘状态为“missing 失败”，继续使用IBM storage manager对，从存储调出服务器故障日志，以进一步分析。
客户运维工程师在服务器数据恢复工程师罗工的帮助下将服务器断电，全部硬盘进行物理顺序编号标记，按各自槽位标识并取出，硬盘数据恢复工程师罗工进行物理检测。工程师通过P3000 sas镜像设备对全部硬盘进行简单检测，除6号盘无法认盘外，8号盘是坏道，10号盘SMART表报错，状态和在IBM存储日志中报告一致。
3、->数据恢复方案
本方案将对服务器阵列盘只读不写方式，备份全成员盘，以全面确保数据安全：
IBM成员盘为光纤非标硬盘，520K/扇区。找4TB镜相备份盘两个，先镜相并替换这两块坏的硬盘 520to520操作花了1天，再镜相其它10块盘花1天操作时间，共计两天。
镜像硬盘，组虚拟阵列，在虚拟阵列中恢复数据
优点：镜像完成以后，不再使用原有硬盘，可以做多样化组合尝试;不会影响原盘数据，恢复的安全性、可逆性极强。
缺点：耗时长;数据一般情况可以完整恢复，但如果遇到硬盘损坏较多，也有可能是部分恢复。
重组raid阵列
恢复oracle数据库
在dmp恢复的过程中，oracle数据库出现报错，内容为“imp-0008”错误，数据库数据恢复工程师对数据库进行分析，导致数据库报错的原因为dmp文件有问题。服务器数据恢复工程师重新对raid结构进行分析重组，重新导出dmp文件和dbf原始库文件并测试，接着对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过测试。 数据库工程师到达现场，和用户沟通后决定使用恢复出来的dbf原始库文件进行操作，以确保能把数据恢复到最佳状态。
数据库恢复过程
1.把数据库文件拷贝到原数据库服务器中，路径为/home/oracle/tmp/syntong. 在根目录下创建了一个oradata文件夹作为备份，并把备份的整个syntong文件夹拷贝到oradata目录下。然后更改oradata文件夹及其所有文件的属组和权限。 2.备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。配置监听，使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询后，了解到环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查询没有问题。启动数据库到open状态。出现报错： ORA-01122: database file 1 failed verification check/frombyte.com ORA-01110: data file 1: /oradata/syntong/system01.dbf ORA-01207: file is more recent than control file - old control file 3.经过进一步的检测和分析，判断此故障为控制文件和数据文件信息不一致，这是一类因断电或突然关机等引起的常见故障。 4.对数据库文件进行逐个检测，检测到所有数据文件没有物理损毁。 5.在mount状态下，对控制文件进行备份，alter database backup controlfile to trace as /backup/controlfile;对备份的控制文件进行查看修改，取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。 6.关闭数据库，删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。 SQL>startup nomount/frombyte.combr/>SQL>@controlfile.sql <="" a="" style="font-family: -apple-system, "Helvetica Neue", Helvetica, Arial, "PingFang SC", "Hiragino Sans GB", "WenQuanYi Micro Hei", "Microsoft Yahei", sans-serif; -webkit-font-smoothing: antialiased; margin: 0px; padding: 0px; max-width: 100%;">7.重建控制文件完成后，直接启动数据库，报错，需要进一步处理。 SQL> alter database open; alter database open/frombyte.com * ERROR at line 1: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: /free/oracle/oradata/orcl/system01.dbf 然后执行恢复命令： recover database using backup controlfile until cancel; Recovery of online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0 Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log … 做介质恢复，直到返回报告，恢复完成。 8.尝试open数据库。 SQL> alter database open resetlogs; 9.数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。 10.对数据库进行各种常规检查，没有任何错误。 11.进行emp备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。一切正常，本次数据恢复成功。
数据恢复结果验证
北京技佳瑞康科技有限公司厦门分公司的罗工和客户方一起努力，历时8天，数据100%恢复成功，客户方工程师对所有数据和ORACLE数据库进行现场验证，数据恢复完美验证。
【服务器存储安全建议】
1.尽量保证机房电源供应稳定，以减少电源异常对主机及存储的冲击; 2.最好为重要的服务器及存储配置UPS，可在机房意外断电的情况下保证核心业务系统能继续维持一定时间的正常工作，从而为企业寻求应急解决方案赢得宝贵的时间; 3.对于服务年限已久的服务器应定期进行安全状况检查，并对其整体运行状态进行评估以决定是否进行硬件及系统的全面升级，同时提前制定突发数据灾难的紧急处理方案，以降低数据灾难带来的业务损失。
总结：HDS高端存储虽然稳定，但也是要经常机房巡检，数据还是要有备份，有备无患!很多时候物理层恢复了，但是存储的状态还是不行或是硬盘状态不对，类似于我去年恢复的HP XP2400上面挂载了220多个硬盘，针对多盘的服务器，一定要思路和逻辑清晰，方案成熟后再着手去恢复处理
北京技佳瑞康科技发展有限公司成立长2012年，国家保密局涉密数据恢复资质单位，总部位于北京，在上海、深圳、厦门、南京等地设有分公司http://www.databack.com.cn ，联想集团数据恢复供应商， 2017-2019北京市政务信息安全应急保障单位，北京市诚信创建企业，中国石油IBM 渣打银行数据恢复服务商，针对服务器和高端存储，机房云数据故障等应急服务有丰富的经验。
