服务器数据恢复环境：IBM DS系列存储服务器；16块容量600G的FC硬盘。
故障：存储服务器前面板10号和13号硬盘故障灯亮，存储映射到redhat上的卷挂载不上，业务下线。服务器管理员联系北亚数据恢复中心进行服务器数据恢复。
服务器数据备份和测试过程：1、到现场后，北亚数据恢复工程师通过storage manager连接到存储查看当前存储状态，存储报告逻辑卷状态失败。物理磁盘状态：6号盘报告“警告”，10号和13号盘报告“失败”。2、通过storage manager将当前存储的完整日志备份下来，通过解析备份出来的存储日志，北亚数据恢复工程师获取了关于逻辑卷结构的部分信息。3、将16块FC盘粘贴标签，按照原始槽位号登记后从存储中移除，使用FC盘镜像设备“R510+SUN3510”对16块FC盘进行粗略测试，16块盘均能正常识别。分别检测16块盘的SMART状态，发现6号盘的SMART状态为“警告”，和在IBM storage manager中报告一致。4、在windows环境下将设备识别出来的FC盘在磁盘管理器中标记为脱机状态，为原始磁盘提供一个写保护功能。北亚数据恢复工程师然后使用软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到逻辑磁盘并以文件形式保存。在镜像过程中发现6号磁盘的镜像速度很慢，结合先前对硬盘SMART状态检测时发现的问题综合判断，6号盘应该存在大量损坏以及不稳定扇区，导致一般应用软件无法对其进行操作。5、使用坏道硬盘镜像设备对6号硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现6号盘的坏道并不多，但是存在大量的读取响应时间长的不稳定扇区。于是北亚数据恢复工程师调整6号盘的拷贝策略，将“遇到坏道跳过扇区数”和“响应等待时间”等参数做修改后继续对6号盘进行镜像操作。同时观察剩余盘镜像的情况。6、完成全部镜像后查看日志，发现在storage manager和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不规律的坏道分布，通过使用软件定位到目标镜像文件分析坏道列表发现，ext3文件系统的部分关键源数据信息已经被坏道破坏，只能等待6号盘镜像完毕后，通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。7、6号盘镜像完成，但是先前为了最大限度备份出有效扇区以及为了保护磁头设置的拷贝策略会自动跳过一些不稳定扇区，所以现在的镜像是不完整的。北亚数据恢复工程师调整拷贝策略，继续镜像被跳过的扇区，完成6号盘所有扇区的全部镜像。8、得到了所有硬盘的物理扇区镜像，在平台下使用软件将所有镜像文件全部展开，根据对ext3文件系统的逆向以及日志文件的分析，北亚数据恢复工程师获取到了16块FC盘在存储中的盘序、RAID的块大小、RAID的校验走向和方式等信息。北亚数据恢复工程师尝试通过软件的方式虚拟重组RAID，RAID搭建完成后进一步解析ext3文件系统，通过和服务器管理员沟通提取出了一些oracle的dmp文件，服务器管理员尝试进行恢复。9、在dmp恢复的过程中，数据库报告imp-0008错误，通过仔细分析导入dmp文件的日志文件，北亚数据恢复工程师发现恢复的dmp文件存在问题所以导致dmp导入数据失败。北亚数据恢复工程师立刻重新分析raid结构，进一步确定ext3文件系统被破坏的程度。经过数小时的努力，重新恢复dmp文件和dbf原始库文件，将恢复出来的dmp文件移交给服务器管理员进行数据导入测试，测试没有发现问题。然后对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过测试。
服务器数据库恢复流程：1、 拷贝数据库文件到原数据库服务器，路径为/home/oracle/tmp/syntong作为备份。在根目录下创建了一个oradata文件夹，把备份的整个syntong文件夹拷贝到oradata目录下，然后更改oradata文件夹及其所有文件的属组和权限。2.、备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。配置监听，使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询后，确认环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查询没有问题。启动数据库到open状态。出现报错：
然后执行恢复命令：
做介质恢复，直到返回报告，恢复完成。相关推荐
