数据恢复

数据库故障状况： 因为机房异样断电，Oracle数据库重新启动后报错：“system01.dbf须要更多的复原来放弃一致性，数据库无奈关上”。Oracle数据库没有备份，归档日志不间断。管理员分割到咱们数据恢复核心寻求帮忙。管理员提供了故障数据库的在线文件，须要复原zxfg用户下的数据。 数据库数据恢复计划： 检测数据库故障，尝试挂起并修复数据库，解析数据文件。 数据库数据恢复过程： 1、检测数据文件的完整性。 后果发现SYSAUX01.DBF文件数据块（Data）检测失败40页，索引页（Index）检测失败29页，能够初步判断SYSAUX01.DBF存在坏块。通过dbv对数据文件的完整性进行测验，确认了SYSAUX01.DBF存在坏块，其余文件通过检测都是残缺的。 2、利用管理员提供的数据库在线文件在本地挂起数据库，修复故障数据库并导出数据。 a、创立新的windows server零碎，装置和用户原始环境数据库版本统一的oracle数据库，挂起数据库。 b、启动数据库报ORA-01110谬误，System01.dbf须要更多一致性复原。应用recover database命令，利用在线日志做介质复原。 c、故障数据库的管制文件已被批改，须要应用管制文件复原数据库。 d、复原数据库须要的归档日志曾经失落，只能应用cancel参数进行不完全恢复。 e、再次执行alter database open命令，关上数据库。 f、查问实例状态，数据库报ora_00600谬误；进行其余查问发现一些查问能够进行，一些查问报错，报错都是ora_00600谬误。 g、查看正告日志，追踪文件，查看外部错误代码；正告日志局部内容如下：ORA-00600: internal error code, arguments: [13013], [5001], [267], [8456009], [5], [8456009], [17], [], [], [], [], []Non-fatal internal error happenned while SMON was doing logging scn->time mapping. h、用expdp/exp工具导出数据库。expdp导出数据库报错，和下面查问报同样的谬误。sysaux01.dbf文件损坏导致expdp工具不可用，导出数据库失败。 尝试应用exp导出数据库然而报同样的谬误。数据库报重大外部谬误，导出工具exp无奈应用，甚至一些查问都不能进行，导出数据库失败。 i、通过下面的尝试，根本能够确定故障数据库的复原曾经不可能。数据库数据恢复工程师应用北亚自主研发DBF解析工具获取数据。 j、迁徙对象到数据库中。创立数据库，在数据库中创立用户，为用户调配表空间，解锁用户并受权。而后通过数据搭桥的形式，将解析到的用户对象迁徙到数据库中。 k、应用toad for oracle工具验证数据。 l、应用exp或者expdp导出zxfg用户下的所有对象。本案例是采纳exp导出数据：命令如下：exp system/abc  file=C:\test\dump\zxfg.dmp log=C:\test\dump\zxfg.log owner=zxfg m、查看导出数据库的dmp文件及导出日志，确保导出的文件没有问题。管理员将导出的数据导入，查看导入数据的完整性，没有发现问题，复原进去的数据残缺可用。

服务器数据恢复环境：别离由4块SAS硬盘组成的两组raid5磁盘阵列，并且两组raid5磁盘阵列划分LUN，组成LVM构造，格式化为EXT3文件系统。 服务器raid5故障：一组raid5中的一块硬盘因为不明起因离线，热备盘顶替离线硬盘上线开始同步数据。但在热备盘同步数据的过程中又有一块硬盘离线，热备盘同步数据失败，一组raid5磁盘阵列解体，LVM构造不残缺，文件系统无奈失常应用。管理员分割咱们数据恢复核心进行数据恢复。服务器数据恢复工程师拿到故障服务器硬盘后，对两块离线硬盘进行检测，后果发现先离线的硬盘无奈辨认，初步推断这块硬盘有硬件故障，须要对其进行收盘修复。后离线的那块硬盘能够辨认进去。 服务器数据恢复过程：1、硬件工程师对故障硬盘进行收盘修复。收盘后发现盘片划伤重大无奈修复，只能对故障磁盘阵列进行缺盘解决。2、对故障raid磁盘阵列的其余磁盘进行全盘镜像备份，对另一组完整的raid磁盘阵列的全副磁盘进行全盘镜像备份。后续所有的数据恢复操作都在镜像文件上进行，防止毁坏原始数据。备份截图： 3、服务器数据恢复工程师基于镜像文件剖析底层数据。通过解析EXT3文件系统构造，获取到两组raid5磁盘阵列的盘序、条带大小、校验方向等raid信息。通过获取到raid信息重组两组raid磁盘阵列。两组raid磁盘阵列的块大小皆为64K，校验方向为左同步。对故障raid磁盘阵列进行重组时进行缺盘解决。 4、重组出两组raid磁盘阵列之后，通过剖析两组raid磁盘阵列中的底层数据北亚服务器数据恢复工程师找到LVM的构造信息，剖析LVM构造并将两组raid磁盘阵列中作为PV（LVM物理卷）的LUN导出。应用工具重组两个PV从新生成LVM逻辑卷。 5、实现LVM的重组后，服务器数据恢复工程师解析LV（逻辑卷）中的EXT3文件系统，复原并导出其中的全副数据。由用户亲自对复原进去的数据进行验证，没有发现发现问题，复原进去的数据残缺无效。以下为局部复原进去的数据：

Oracle数据恢复故障&剖析： 关上oracle数据库报错“system01.dbf须要更多的复原来放弃一致性，数据库无奈关上”。用户找到咱们数据恢复核心，提供了数据库oraclehome目录的所有文件，要求复原zxfg用户下的数据。 北亚数据库数据恢复工程师检测故障数据库文件，发现sysaux01.dbf有坏块，文件损坏。因为故障数据库没有备份，不能通过备份去复原数据库。 “system01.dbf须要更多的复原来放弃一致性”报错的起因个别有以下几种：管制文件损坏、数据文件损坏，数据文件与管制文件的SCN不统一等。对数据库文件进一步检测、剖析，发现sysaux01.dbf文件有坏块。修复并启动数据库后，发现有很多查问报错，export和data pump工具不能应用。查问告警日志，剖析报错，发现是因为sysaux文件损坏导致的上述谬误，从数据库层面不能修复数据库。因为system和用户表空间的数据文件都是失常的，能够利用底层解析数据文件来复原用户的数据。 Oracle数据恢复故障检测和修复过程： 1、利用DBV检测数据文件。 剖析后果发现SYSAUX01.DBF文件数据块（Data）检测失败40页，索引页（Index)检测失败29页，其余文件检测失常。 2、修复数据库，关上数据库。 3、查询数据库报错，export和data pump报错。 查阅大量材料，进行各种尝试，最终发现Oracle数据库的这种外部谬误目前不能通过命令修复。 4、北亚数据恢复工程师利用底层解析数据库文件，将ZXFG用户的数据导入到新的数据库中。用户亲自检测复原进去的数据，没有发现问题，完全恢复出用户须要的数据。

存储数据恢复环境：NetAapp某型号存储，文件系统为WAFL。 存储故障：工作人员误操作将NetApp存储中的重要数据删除，急需进行数据恢复操作，分割咱们数据恢复核心寻求帮忙。 存储数据恢复过程：1、对存储设备所有硬盘以只读模式做镜像备份，后续的数据恢复操作都是基于镜像文件进行，防止对原始数据造成二次毁坏。2、数据恢复工程师基于镜像文件剖析底层二进制数据，剖析数据分布的根本状况。3、依据剖析进去的数据分布状况计算Raid的根本信息，基于Raid信息通过北亚自主开发的虚构Raid控制器进行Raid重组。4、在重组的Raid上重构Storage Pool，导出失落数据的逻辑卷。5、对NetApp存储进行底层WAFL文件系统的差异化测试，剖析差别区域的规定。6、北亚数据恢复工程师编写WAFL文件系统解析程序对失落数据的卷进行WAFL文件系统解析。7、剖析删除文件的节点索引信息，北亚数据恢复工程师编写针对删除文件索引的解析程序解析删除节点，复原删除数据。8、由用户亲自对复原进去的数据进行验证。如果发现数据有问题，反复下面的2-7步的数据恢复操作。9、最终确定所有复原进去的数据没有问题后，按要求移交数据。

服务器数据恢复环境：一台linux网站服务器；一块SATA硬盘；运行50个左右的网站。 服务器故障&剖析：服务器失常运行过程中宕机，管理员尝试重新启动失败。将硬盘从服务器上拆下来进行检测发现100个左右的坏扇区。送到某数据恢复服务商修复坏道后进行数据恢复，破费了3天工夫数据依然没有复原胜利。管理员分割到咱们数据恢复核心进行数据恢复。北亚服务器数据恢复工程师理解了服务器故障后，初步推断：1、呈现坏道后，用户可能试图进行主动或手工的fsck操作，导致进一步的数据毁坏。2、以局部块组全为0看，有可能做过未实现的mkfs操作。3、送修的数据恢复过程有毁坏数据的可能性。 服务器数据恢复过程：1、首先通过软件对故障服务器硬盘进行残缺的镜像备份，后续的数据恢复操作都在镜像中实现，防止对原始数据造成毁坏。2、基于镜像文件进行数据分析。整块硬盘由两个分区组成：“100M的boot分区”和“/分区(通过LVM治理)”，文件系统均为EXT3。根分区超级块失常，依据超级块查看第一块组形容表失常，但节点区全为0。3、依据块组形容表剖析其余块组，发现前27个块组全副为0，但块组前后的数据区显著有用户数据存在。两头块组区元数据(形容表、节点、BITMAP等)失常，最初局部块组的元数据区全副为0。4、试图查找根目录，以根目录为线索，尝试复原根目录节点区。5、北亚服务器数据恢复工程师以生成的根目录节点区与根目录记录生成文件系统树，实现这步操作后曾经能够看到大量数据，文件系统构造失常。但局部文件或文件夹的节点为0，通过节点跟踪，发现节点区位于文件系统前局部及后局部。6、试图复原节点区为0的文件与文件夹，文件夹大部分复原胜利，但文件大部分无奈复原。7、试图复原用户之前做过的.TAR.GZ备份包，复原胜利，但关上时提醒出错，两头数据被毁坏，只能无限导出局部网站。到这步数据恢复工作实现。 服务器数据安全Tips:1、重要的数据不要存储在单盘上，组建一组RAID是比拟好的数据存储形式。2、肯定要做好备份，备份包不要放到同一存储媒介上。即便寄存在同一媒介也不要放到同一分区下。3、硬盘呈现故障后千万不要重复尝试各种复原或者修复的操作，最须要做的就是尽快对故障硬盘做残缺备份。4、尽可能抉择业余正规的数据恢复机构进行解决，不正规业余的机构或集体会无心或无意地对故障盘数据进行二次毁坏。

虚拟机数据恢复环境：故障虚拟机是由物理机迁徙到EXSI下面的，迁徙实现后做了一个快照；故障虚拟机运行SQL的数据库，记录了6年的数据；EXSI上共有二十几台虚拟机；EXSI连贯的存储是一台HP EVA存储，所有的虚拟机（包含故障虚拟机）都放在EVA上。 虚拟机故障形容&剖析：因为工作人员的误操作将快照还原了。快照是3年前虚拟机做完迁徙时做的，也就是说虚拟机还原到3年前的状态，最近3年的数据都被删除了。管理员分割咱们数据恢复核心进行数据恢复。还原快照相当于删除数据，意味着底层的存储空间会开释一部分。为了不让这部分开释的空间被重用笼罩，就必须将连贯到这台EVA存储的所有虚拟机都关掉。不能长时间的宕机的重要虚拟机须要迁徙到别的EXSI上。用户这里就有一台虚拟机不能关机，只能做热迁徙。因为vmware的热迁徙是须要建设N多个快照来实现迁徙的，这会给前面的复原快照工作带来很多麻烦。迁徙完所有虚拟机后须要对底层的EVA存储做镜像，然而镜像整个存储须要的工夫太长，用户比拟焦急。最初只能将EVA存储以只读的形式挂载到一台服务器上，以只读的形式复原数据。 虚拟机数据恢复过程：Vmware的文件系统是Vmfs，所有的虚拟机都寄存在这个文件系统中。Vmfs文件系统默认会将整个磁盘分成1M大小的Block，调配给文件的最小单位为一个Block。Vmfs文件系统中有一片区域描述这些1M Block的应用状况，而每1024个Block（也就是1GB）会用一个MAP来记录。这个MAP外面记录的1M Block在物理磁盘上不肯定是间断的。但这个MAP所记录的所有1M Block肯定是同一个文件的。能够了解为一个文件是由N多个MAP中的1024个Block组成的，即FileSize = N MAP 1024（Block）。Vmware的快照就是一个文件，还原快照也就是删掉一个文件。在Vmfs文件系统中，删除一个文件只会删掉文件的索引项，而不会删掉文件的理论数据以及指向数据的MAP。1、北亚数据恢复工程师提取整个vmfs文件系统中闲暇的MAP，在闲暇的MAP中找到一个合乎快照文件头构造的MAP。2、依据快照文件的构造，提取快照文件剩下的碎片。3、提取完快照文件后，将快照文件和原vmdk合并生成新的vmdk，新的vmdk中蕴含了所有的数据。4、挂载新的vmdk并解释外面的数据。由用户亲自对复原进去的数据进行验证。 虚拟机数据恢复后果：因为用户做过虚拟机的热迁徙的操作，导致快照中的几个碎片被重用。最终复原的数据中，最新的数据不可用。但因为须要复原的数据是数据库，每天都备份2次。尽管最新的数据不可用，但备份的数据可用。整个复原工作耗时2天。

服务器数据恢复环境：LINUX操作系统服务器；4块SAS磁盘组成RAID5阵列；共两个卷：一个为/boot，另一个是LVM；LVM中又划分了一个根分区和一个替换分区。 服务器故障&剖析：服务器在运行时候忽然死机，管理员进行重启操作，无奈进入操作系统，然而raid失常。管理员分割咱们数据恢复核心寻求帮忙。管理员要求复原的数据是存储在根分区中的MYSQL数据库和网站备份的tar.gz文件，文件系统为EXT4。通过北亚服务器数据恢复工程师检测，初步判断是文件系统故障导致的数据失落。 服务器数据恢复过程：1、因为RAID没有发现问题，服务器数据恢复工程师对故障服务器进行检测后，将故障服务器所有硬盘中的数据都残缺镜像到北亚数据恢复核心的平安存储中。2、基于镜像文件进行故障起因剖析并制订针对故障服务器的数据恢复计划。3、通过进一步剖析发现EXT4文件系统超级块、块组描述符、块位图和大部分I节点都失常，但局部负荷重的MYSQL表的文件的I节点所在的块全被FF填充，EXT4一个I节点占256 byte，此EXT4文件系统块长度为4KB，一个块可存储16个I节点，一个文件或一个目录都会应用一个I节点，所以一个文件I节点呈现问题，会额定影响其它的15个文件。北亚数据恢复核心也解决过多例I节点块被FF填充的故障，可能是EXT3/4系列文件系统的BUG。4、I节点块被FF填充这类故障产生的起因大同小异。北亚数据恢复核心凭借对LINUX文件系统多年的深入研究和丰盛的数据恢复教训，修复好损坏的EXT4文件系统，导出MYSQL数据库和须要的网站备份tar.gz文件。通过管理员的亲自验证，数据库和tar.gz文件均失常，数据恢复实现。 服务器数据安全Tips：1、服务器产生故障后，用户切忌再对服务器进行任何操作，也切忌随便取出硬盘，免得弄乱程序减少前期数据恢复的难度。2、如果曾经取出硬盘，标记好硬盘的程序。3、求助业余正规的服务器数据恢复机构，切忌因为报价便宜而把数据恢复的工作轻易交付给一家公司。4、如果单位服务器内存储的是保密度较高或者较为重要的数据资料，倡议装备单位外部的服务器数据恢复设施，防止在服务器数据恢复的过程中呈现数据泄密的危险。

服务器数据恢复环境：HP DL系列某型号服务器；通过hp smart array控制器挂载磁盘阵列；由14块SCSI硬盘组成raid5磁盘阵列；LINUX操作系统，搭建了NFS+FTP，作为公司外部文件服务器应用。 服务器故障&剖析：服务器机房搬迁，拔掉各种连接线并对设施做了打扫，而后在新机房连贯好线路之后服务器无奈辨认RAID，提醒未做初始化。管理员分割咱们数据恢复核心寻求帮忙。服务器数据恢复工程师对故障服务器进行简略的初检，初步判断故障服务器数据失落是由raid信息失落所导致的。RAID5中的冗余采纳双循环的校验形式。 服务器raid数据恢复过程：1、先将SCSI硬盘柜间接连贯到不蕴含有RAID性能的SCSI扩展卡上。2、服务器数据恢复工程师在北亚专用数据修复平台上以单盘的形式连贯故障服务器阵列中的所有硬盘。3、为了爱护原始数据，以只读形式对所有硬盘做残缺镜像，把镜像存储于带冗余爱护的设施上。4、服务器数据恢复工程师基于镜像文件剖析原RAID的双循环校验参数并搭建虚构raid。5、在虚构RAID去掉最早离线的盘并解释文件系统，此时raid数据曾经能够导出。6、在用户原服务器上从新搭建配置RAID。7、最初通过网络dd、NFS、SAMBA、FTP、SSH等数据传输方式把所有数据传回新建的raid磁盘阵列中。全副数据恢复工作历时2天，Raid中所有数据全副复原。

HP-Lefthand存储构造介绍：Lefhand存储反对搭建RAID5、RAID6、RAID10磁盘阵列，反对卷快照，卷动静扩容等。 服务端： 客户端： Lefthand存储共分为物理磁盘、逻辑磁盘、逻辑卷三个级别，其中物理磁盘是理论的物磁盘，多个物理磁盘组成一个逻辑的磁盘，也就是RAID磁盘阵列，在RAID之上，将不同RAID组成一个大空间，将大空间中不同的区域组成一个卷。 卷由不同RAID的N个不间断的片段组成，是用户的可用空间，存储的是文件系统以及用户的数据。RAID是Lefthand能辨认的最小单元，大多是RAID5或RAID6，RAID的后面会有一部分空间用来存储记录这些片段的MAP。记录所有数据的磁盘就是物理磁盘，并且数据是不间断的，如果下层是RAID5或RAID6。那么物理磁盘中还包含校验数据。 上面分享一个Lefthand存储的数据恢复案例： 存储故障：某法院的一台某型号的Lefthand存储的存储系统因raid磁盘故障导致存储解体，更换磁盘强制上线后存储仍然不可用。磁盘阵列如下图： 数据恢复过程：1、硬件工程师对硬盘进行检测，没有发现硬件问题。2、北亚服务器数据恢复工程师对故障存储中所有磁盘进行全盘镜像并对镜像文件进行剖析。3、通过剖析获知底层的RAID是一个HP双循环RAID5，因为第一组RAID5一切正常，所以能够判断第二组RAID5中的掉盘数量至多为2块。4、应用穷举+校验剖析出最早掉线的磁盘并踢出，重组raid并生成数据。（穷举法：假如其中某一块磁盘是最早掉线的，踢掉此盘，重组RAID并生成全副数据，最初将数据挂载到存储设备上，看数据是否正确。如果数据不正确，那么再假如另一块盘是最早掉线的，顺次循环。尽管通过这种计划必定能找到最早掉线的硬盘，然而因为每次重组RAID生成数据破费工夫太长，并且准确性很低，所以不倡议独自应用这种计划。穷举+校验这种计划和穷举法一样，假如某个磁盘是最早掉线的，踢掉磁盘后重组RAID，但不是生成全副的数据，而是只生成后面几G的数据，因为故障存储外部存放数据的索引表位图位于RAID的前几个G之内。只须要查看这个索引表的位图信息是否正确就能够判断此RAID是否正确，如果正确就生成此RAID的数据即可实现RAID的重组。）5、将生成的数据和第一组完整的RAID一起挂载到故障存储设备上。启动存储，下层卷可用，查看最新文件一切正常，数据恢复胜利。

服务器数据恢复环境：两台SPARC SOLARIS零碎通过光纤交换机共享同一存储作为CLUSTER应用，失常状况下A服务器工作，当A服务器产生故障宕机后即可将其关机而后开启B服务器接管。 服务器故障：因为服务器配置不当导致两台服务器没有做好对存储的互斥。管理员进行巡逻时开启B服务器，查看到B服务器连贯了一组未知的大容量磁盘。因为B服务器并未启用处于闲置的状态，所以管理员本能的认为B服务器连贯的那一组大容量磁盘也处于闲置状态，于是将整个磁盘的某个分区做了newfs。没有想到这个磁盘就是那个共享存储，没多久A服务器报警并宕机。管理员重启了A服务器，发现所有的文件系统均无奈mount。管理员执行了fsck，除了在B机做过newfs的文件系统其余分区的数据都修复胜利，在B机做过newfs的文件系统的根目录下只有一个lost+found文件夹，外面有大量数字标号的文件。故障文件系统存储了两组ORACLE实例，原构造为UFS，约有200~400个数据文件须要复原。 服务器故障剖析：光纤设施的共享抵触案例很多。本案例中A服务器与B服务器同时对UFS这个单机文件系统进行拜访，两台服务器都以想当然的独享形式对存储进行治理。A服务器失常治理的文件系统底层上其实曾经被B服务器做了文件系统的初始化，A服务器从缓冲区写入文件系统的数据也会毁坏B服务器初始化的后果。B服务器newfs实际上会间接作用于原先的文件系统之上，但本案例与单纯的newfs有些不同：在A服务器宕机之前会有一小部分数据(包含元数据)回写到文件系统。如果newfs的构造与之前的雷同，数据区是不会被毁坏的，如果有一小部分元数据存在，还是有可能复原局部数据的。UFS是传统的UNIX文件系统，以块组切割，每块组调配若干固定的inode区。如果文件系统newfs的构造与之前的雷同，文件系统最重要的inode区便会全副初始化，之前的无奈保留。因为inode治理着所有文件的重要属性，所以单纯从文件系统角度复原数据的难度很大。好在oracle数据文件的结构性很强，同时UFS文件系统有肯定的存储法则，能够通过对oracle数据文件的构造重组，间接将数据文件、管制文件、日志等复原进去。同时oracle数据文件自身有表名称形容，能够反向推断原来的磁盘文件名。 服务器数据恢复过程：1、对故障的文件系统做镜像备份。2、北亚服务器数据恢复工程师针对整个镜像文件做齐全的oracle数据结构剖析、重组。3、参考ufs文件系统结构特征，北亚工程师对局部构造太乱，无奈重组的文件进行辅助剖析。4、利用复原进去的数据文件、管制文件在oracle平台复原数据库。最终复原出所有数据库数据。 服务器数据恢复Tips：fsck是很致命的操作，在执行fsck操作之前最好做好备份。光纤存储的不互斥是很多数据劫难产生的起因，应审慎部署与施行。

服务器数据恢复环境： IBM某型号服务器；4块SAS磁盘组建的RAID5磁盘阵列；服务器操作系统windows server；一个单节点Oracle，数据存储为文件系统，无归档。oracle应用默认的users表空间，users表空间下仅有一个不到1G的数据文件。 服务器故障： 工作负荷过重导致RAID磁盘阵列呈现故障，管理员为了解救数据执行了重建RAID的操作，RAID初始化过程中一磁盘呈现故障，RAID初始化中断，有大量数据被同步毁坏。此时重建的RAID磁盘阵列可拜访，零碎能够失常启动，oracle数据库所在的分区报错无奈关上，执行chkdsk操作后能失常关上，但数据库无奈启动。管理员在原盘上重新安装了oracle数据库并导入了以前备份的dmp文件，但数据相差太大。管理员分割咱们数据恢复核心寻求帮忙。 服务器数据恢复过程： 1、北亚数据恢复核心安顿Oracle工程师和服务器数据恢复工程师到现场进行数据恢复。因为重建RAID很可能会造成严重破坏，所以工程师达到现场后首先对RAID层进行剖析，剖析后发现重建的RAID的块大小、盘序都和原来的RAID一样，初始化仅同步了大量数据，RAID层损坏不重大，数据库没有被毁坏。 2、剖析前面管理员对oracle数据库所在分区执行chkdsk和重装oracle数据库并导入dmp文件操作造成的毁坏进行检测剖析：因为Chkdsk操作不会毁坏数据区，只会对文件系统元数据区进行批改，执行chkdsk后数据库文件仍无毁坏，最多只是文件的MFT或目录项被毁坏。然而重装 Oracle和导入dmp文件的操作不仅对文件系统元数据区进行了毁坏，还对数据区进行了笼罩。 3、对oracle所在分区的NTFS文件系统进行剖析。剖析后发现原所有oracle数据文件的的MFT均被笼罩，NTFS日志也被轮回笼罩，从NTFS元数据区找不可利用信息。服务器数据恢复工程师应用北亚数据恢复核心自研的Oracle恢复程序对整个分区进行复原。通过Oracle恢复程序扫描发现Oracle实例为ANSORA，扫描出一个原始残缺的管制文件和一个原始残缺的undotbs表空间数据文件。然而重要的system和users表空间数据文件都有不同水平的损坏，其中system表空间的数据文件仅剩中后部的一小部分，而users表空间的数据文件也有一小部分被笼罩。 4、提取出找到的完整数据，对重大损坏的数据库进行修复。因为system表空间不可用，无奈失去数据字典。在和管理员沟通后确认了三张重要的表，从管理员imp回去的数据库中获取到这三张表的构造，再从复原进去的users表空间的数据文件中找到对应的segment。有一张表无奈对应上，再次询问管理员得悉这张表有过更改字段的操作，再构建新的表构造对应上users表空间数据文件中的segment，而后应用oracle dul工具提取出这三张表的数据。通过管理员验证后，确认复原进去的数据没有问题，本次数据恢复胜利。

服务器数据恢复环境：农科院某研究所DELL某型号服务器；15块1TB硬盘搭建为RAID5磁盘阵列；磁盘阵列只蕴含一个卷组，卷组占用阵列全副空间，该卷组只有一个起始地位为0扇区的XFS裸分区。 服务器故障：服务器失常运行过程中一块硬盘离线，管理员对磁盘阵列进行数据同步操作，在进行数据同步的过程中又有一块磁盘报警，磁盘阵列同步数据失败，服务器raid阵列解体，无奈失常工作。管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、服务器数据恢复工程师查看故障服务器raid阵列中所有磁盘的状态，发现阵列中最先离线的硬盘访问速度迟缓，第二块离线的磁盘有大量坏扇区，其余磁盘无显著物理故障。RAID5阵列只容许一块磁盘离线，当第二块磁盘离线后阵列就无奈失常工作。故障服务器的解体是因为第二块磁盘的离线造成的，所以第二块磁盘中的数据是本案例服务器数据恢复的要害。2、对故障服务器中所有硬盘做镜像备份，所有数据恢复操作都在镜像文件上进行，不影响原始磁盘数据。3、服务器数据恢复工程师对故障服务器中的15块硬盘进行异或测试，测试全副通过，没有发现显著谬误。4、北亚数据恢复工程师计算出第二块离线硬盘损坏扇区地位的数据，并将其写入镜像文件。5、剖析原RAID5的组成构造，构建虚构RAID环境并验证RAID构造是否正确。6、将第二块离线磁盘的镜像备份到新硬盘，并将其强制上线，更换第一块磁盘，并对其进行同步。(留神：此过程危险，操作需谨慎！)7、拷贝数据。 服务器数据恢复论断：因为异或测试齐全通过，从侧面证实了该服务器故障产生后没有写入新的数据或构造被改变过。这种状况下能够依据阵列中其余的好硬盘计算出坏硬盘对应地位的数据。复原实现后，目录构造残缺，重要文档全副完整，FSCK无任何谬误提醒。用户认可复原进去的数据。

服务器数据恢复环境：IBM某型号服务器；5块SAS硬盘组成RAID5磁盘阵列；存储划分为1个LUN和3个分区：第一个分区寄存windows server零碎，第二个分区寄存SQL Server数据库，第三个分区寄存备份文件。 服务器raid故障：服务器在运行时候raid磁盘阵列解体，服务器管理员分割咱们数据恢复核心进行数据恢复。达到用户现场后，服务器数据恢复工程师对故障raid磁盘阵列进行了初检，后果发现故障服务器raid5中的2块磁盘呈现物理故障离线，这是导致服务器raid磁盘阵列解体的起因。 服务器raid数据恢复过程：1、把故障服务器raid中所有磁盘编好号取出并做只读镜像备份，用只读形式剖析镜像文件中的所有数据。2、剖析所有磁盘在原始RAID中的组合参数，剖析数据过程中发现其中一块离线磁盘损坏重大，是最早离线的硬盘，在其中没有发现最新数据，没有必要对其进行硬件故障修复。所以如果要胜利复原数据必须修复后离线的那块磁盘。3、安顿硬件工程师对后离线的硬盘进行硬件故障修复。4、对磁盘阵列中后离线的磁盘实现硬件修复后，北亚数据恢复工程师依照开始剖析出的原始RAID组合参数虚构重构RAID。重构RAID实现后，三个分区均能失常辨认，分区中所有文件均可见。5、将SQL SERVER数据库文件复原进去并附加到SQL SERVER上进行验证和查看，数据库数据失常，本次数据恢复实现。 正规数据恢复公司服务准则：1、检测收费；2、签订窃密协定；3、数据恢复不胜利不免费；4、数据恢复工作由工程师团队合作分工实现，不是孤军奋战；5、数据恢复前报价，用户确认后工程师开始进行数据修复；6、整个复原过程不会对原盘有任何的写操作，所有数据恢复操作都是在备份数据上进行，以确保原盘的数据齐全。

服务器故障：本案例须要进行数据恢复机器是一台IBM某型号存储，故障为vdisk失落，操作系统中的Oracle数据库无奈失常应用。管理员重建MDisk，把故障存储中的raid10重建为了raid6，而后又再次重建为riad10，这番操作导致服务器对应的存储池中的VDisk失落，下层Solaris操作系统中的Oracle数据库无奈失常应用。用户分割咱们数据恢复核心要求复原服务器Solaris操作系统中的Oracle数据库。 服务器数据恢复过程：1、将所有波及到Oracle数据库的VDisk以只读模式连贯到备份服务器，应用数据备份工具对映射过去的VDisk做只读模式的备份。2、把所有成员盘排好序做标记，而后做只读模式的全盘镜像。3、判断管理员的Mdisk重建操作对数据的毁坏水平。4、剖析重建后的raid6的数据分布规定，计算出RAID6的双校验写到硬盘的具体位置。因为raid6的双校验会毁坏数据区域，针对被毁坏的区域，服务器数据恢复工程师联合raid10的散布规定尽可能的还原出原来的Mdisk。5、对复原进去的Mdisk进行底层卷剖析，取出精简模式的数据MAP并校验数据MAP是否失常。依据精简模式的算法联合数据MAP尽可能的还原VDisk。6、数据库文件复原及数据库文件修复。实现了VDisk的数据恢复后，联合未损坏的VDisk做Oracle数据库页特色扫描，生成相应的数据库文件的特色集。剖析出数据库在所有VDisk中的数据分布MAP来进行数据库文件的复原。借助北亚自研的软件对数据库文件做一致性检测，检测后果文件失常，构造残缺。尝试启动数据库实例并监控状态，一切正常，导出数据库。本次数据恢复胜利。 服务器数据恢复剖析：因为故障存储中某个MDisk被重建，下层VDisk及Oracle数据库无奈失常应用。如果MDisk重建后的raid类型为RAID6（之前为RAID10），局部数据就会被毁坏。最坏状况会有2块盘(RAID6的双校验)的数据被损坏。本案例中，从VDisk层面来看，数据残缺度超过75%。下层Oracle又由多个VDisk组成，下层Oracle层面的数据残缺度超过95%。

服务器数据恢复环境：太原某公司linux操作系统服务器+一台某型号的存储；xfs文件系统。 服务器故障：管理员应用xfs_repair工具试图修复文件系统失败，linux服务器中所有数据失落，管理员分割咱们数据恢复核心寻求帮忙。通过初步诊断后，咱们数据恢复核心从北京总部安顿服务器数据恢复工程师返回用户现场进行故障服务器的数据恢复。 服务器数据恢复计划：1、为了不毁坏故障服务器的原始数据，首先对故障服务器所有硬盘做镜像备份，所有的数据恢复操作都在备份文件上进行。2、剖析XFS文件系统的超级块，获取故障服务器XFS文件系统相干信息。3、尝试将服务器的文件系统构造进行复原。4、由北亚数据恢复工程师编写程序对xfs文件系统进行解析。5、扫描文件节点，而后提取服务器中的数据。 服务器数据恢复过程：1、服务器数据恢复工程师基于备份文件对故障服务器中的XFS文件系统进行剖析，获取到XFS文件系统相干信息。2、解析xfs文件系统，而后扫描文件节点进行数据提取。因为故障服务器的XFS文件系统构造异样，无奈失常解析出文件系统。3、服务器数据恢复工程师试图间接扫描文件节点提取数据，但故障服务器中的XFS文件系统的文件节点全副失落。4、服务器数据恢复工程师通过r-studio针对文件类型进行扫描来复原数据。5、将复原进去的数据让管理员亲自核验，最终确定原服务器中所有数据恢复胜利。6、通过光纤传输将复原进去的数据移交给用户，将存储在北亚数据恢复核心的所有备份数据和复原进去的数据在管理员的见证下进行销毁。 xfs文件系统数据恢复Tips：在应用xfs_repair工具、fsck还是check disk等其余文件系统修复工具时肯定要谨慎。在进行修复前肯定要先备份好数据后再持续进行下一步操作。

服务器数据恢复环境：Dell某型号服务器；6块SCSI硬盘组成raid5磁盘阵列；操作系统为Redhat linux ； 文件系统为ext3文件系统。 服务器故障&剖析：服务器在工作过程中瘫痪，管理员查看后发现raid5阵列中两块硬盘离线，于是对其中一块硬盘进行强制上线操作，然而操作系统不能失常启动。管理员马上把服务器关机，分割到咱们数据恢复核心进行数据恢复。在咱们数据恢复核心接到的服务器数据恢复案例中，raid5两块硬盘离线这种类型的故障非常常见。raid5磁盘阵列只反对一块硬盘离线时的冗余爱护，如果有超过一块硬盘离线，服务器raid5阵列便会瘫痪且不会主动上线。因为一些厂家的raid控制器比拟敏感，raid阵列中硬盘掉线少数状况下是由供电电源稳定、控制器bug等起因造成的，所以掉线盘不肯定有重大的物理故障。通过服务器数据恢复工程师的检测，发现本案例中的raid5阵列故障就是属于此列。如果raid5磁盘阵列中有超过一块硬盘离线，此时进行强制上线操作的危险很大，一旦上线出错就会让raid控制器对数据造成不可逆的损坏。当管理员进入操作系统后，因为文件系统不统一进行修复，服务器中所有硬盘数据不统一，数据恢复难度十分大。 服务器数据恢复过程：1、服务器数据恢复工程师对服务器中所有硬盘进行残缺镜像备份，在备份过程中发现多块硬盘存在坏道但并没有下线，初步判断raid没有读取到硬盘坏道。2、实现备份后北亚服务器数据恢复工程师剖析原服务器的raid组成构造，虚构出raid环境，而后对raid构造进行畸形验证。3、北亚服务器数据恢复工程师人工修改被毁坏的raid构造，将修改后的数据导出到一台两头存储上长期寄存。4、应用完整的硬盘在服务器上搭建新的raid5磁盘阵列，将复原出的数据迁徙到新搭建的raid5阵列中。5、测验复原进去的数据，没有发现异常，数据胜利复原。 服务器数据恢复Tips：raid5磁盘阵列呈现多块硬盘离线，服务器瘫痪的状况下切记不要自觉进行强制上线操作。如果有足够的备用空间，可将源硬盘全副镜像，而后寻求正规业余的数据恢复机构的帮忙。

存储服务器数据恢复环境：某公司一台netAPP某型号存储。 存储服务器故障&剖析：管理员在工作中误删除了NetApp存储中某重要文件夹，刚开始没有怎么在意这个事件，起初发现问题重大了，管理员紧急寻找一家数据恢复公司上门进行存储的数据恢复，从管理员找到咱们进行数据恢复到删除数据这两头曾经距离了几个月的工夫。咱们数据恢复核心安顿数据恢复工程师返回现场对NetApp存储进行初检。尽管数据曾经被删除几个月了，但因为NetApp的文件系统个性WAFL（Write Anywhere File Layout），所以数据被笼罩的几率很低，胜利复原出数据的概率很高。 存储服务器复原过程：1，因为不同型号的WAFL文件系统版本不同，不同版本之间的差距很大，首先数据服务器复原工程师须要依据节点的构造对数据块节点指针进行判断确定文件系统版本。通过北亚服务器数据恢复工程师们对netAPP存储的数据结构进行剖析，最终确定本案例的文件系统版本以及数据块指针。 2，服务器数据恢复工程师剖析扇区后得悉故障netAPP存储的文件系统应用的blocksize为16+2扇区，其中前8个扇区为数据块，后2扇区为block标记。（有的WAFL文件系统版本为了节约磁盘容量，将最初2个扇区内容压缩至数据扇区的最初2个扇区） 3，服务器数据恢复工程师对目录构造进行剖析，netAPP存储的目录构造中寄存了文件、文件夹以及文件系统自身的元信息。该构造寄存了文件的节点（该节点惟一）和父文件夹的节点，与数据节点中的信息统一。 4，北亚数据恢复工程师人工剖析出这些数据恢复所必须的重要信息之后，对故障netAPP存储进行全盘扫描，将数据恢复所须要的节点信息和目录信息扫描进去，而后寄存到数据库中以备后续的数据恢复应用。5，在数据库中依据用户的形容查找出须要的文件夹，建设须要的目录树。北亚数据恢复工程师对故障netAPP存储的算法进行钻研并依据需要编写相应的程序，提供根目录之后就能够通过北亚数据恢复工程师编写的程序提取出用户所需的数据。6、本次服务器数据恢复总共耗时2天半，胜利复原出所有数据。

服务器数据恢复环境：两组由4块SAS硬盘组成的raid5磁盘阵列；ext3文件系统、lvm构造。 服务器故障：磁盘阵列中1号硬盘离线，热备盘启动开始同步数据，在数据同步过程中3号硬盘呈现故障离线，Raid阵列解体，LVM构造不残缺，ext3文件系统无奈失常应用，服务器瘫痪。管理员查看掉线的两块硬盘，发现1号硬盘无奈辨认，3号硬盘能够辨认。管理员分割咱们数据恢复核心进行服务器的数据恢复。 服务器数据恢复计划：拿到故障服务器硬盘后，首先由硬件工程师对故障硬盘进行修复，而后将故障raid阵列中没有掉线的硬盘和另一组失常的raid阵列进行全盘备份。由服务器数据恢复工程师剖析raid获取raid相干信息，依据获取到的raid信息重建阵列；通过剖析找到LVM信息并重组LVM卷，而后进一步剖析EXT3文件系统，复原并导出全副数据。 数据恢复过程：1、由硬件工程师对无奈辨认的1号硬盘进行收盘检测，发现硬盘盘片磨损十分重大，无奈进行数据恢复，在后续的数据恢复过程中只能依照缺盘状态进行解决。2、对故障raid阵列其余硬盘和失常阵列的所有硬盘进行全盘备份，数据备份状况如下： 3、对备份数据进行剖析，对原raid磁盘阵列中的校验形式、条带大小，硬盘盘序等信息进行剖析，并依据剖析获取到的raid信息重组出两组raid阵列。重组raid截图如下： 4、北亚服务器数据恢复工程师将两组raid重组实现后开始剖析底层数据，尝试剖析出lvm构造相干信息并导出作为pv的lun，重组pv并从新生成lvm逻辑卷，过程如下： 5、LVM重组实现之后，北亚数据恢复工程师对LV（逻辑卷）中的EXT3文件系统进行解析，复原并导出其中的全副数据。数据恢复后果如下： 服务器数据恢复后果：因为故障阵列中的1号硬盘盘片划伤重大无奈修复，且局部硬盘中存在坏道，raid构造可能存在缺点。通过用户检测，发现大部分文件都复原进去了，抵赖本次数据恢复后果。

虚拟机数据恢复环境：故障服务器操作系统为Linux零碎；文件系统为EXT4文件系统。 虚拟机故障：故障服务器上的KVM虚拟机被删除，每台虚拟机蕴含一个qcow2格局的磁盘文件，和一个raw格局的磁盘文件。管理员分割咱们数据恢复核心进行数据恢复。 虚拟机1：主数据库服务器虚构磁盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4次要数据：MySQL数据库 虚拟机2：备份数据库服务器虚构磁盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4次要数据：MySQL数据库 虚拟机3：代码服务器虚拟机盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4次要数据：程序代码 虚拟机数据恢复过程：1、剖析EXT4文件系统，定位被删除虚拟机磁盘文件的节点地位；2、获取磁盘文件残留的索引信息；3、校验残留索引信息的正确性，修复毁坏不重大的索引；图为获取的索引等信息： 4、修复实现后，解析残留的各级索引，从虚拟机所在的卷中提取虚构磁盘文件；5、依据虚构磁盘文件的提取状况，获取卷中未被索引到的自由空间；6、校验提取出的磁盘文件的正确性与完整性；7、从自由空间中获取无效信息，北亚数据恢复工程师尝试对虚构磁盘文件进行修补（如节点，目录项，数据库页等信息）。图为提取出的自由空间： 虚拟机数据恢复后果：1、因为索引失落，提取出的虚构磁盘文件并不残缺，针对数据库服务器，数据库文件有失落的状况，能够从自由空间中获取数据库页去对数据库文件进行修补，但因为局部页所在区域被笼罩占用，北亚数据恢复工程师只能尽量多的去补页；2、对于寄存程序代码的服务器中的节点和目录项失落的状况，若节点或目录项有残留，能够尝试去补齐节点和目录项。但发现局部文件的节点和目录项同时失落，依据节点和目录项之间相关联的个性，这种状况下无奈补齐。另依据程序代码文件的个性，不具备肯定的规律性，若其数据区失落，无奈补齐。图为复原出的局部目录构造： 数据验证：在尽可能的尝试对虚构磁盘文件及其中的数据库文件修补之后，由客户用户对数据进行验证。数据有局部失落，无奈复原，但重要数据都复原进去了，数据恢复无效。

服务器数据恢复环境：8块SAS硬盘中的7块硬盘组成RAID5阵列，1块作为热备盘。 服务器故障：故障服务器存储中的RAID5阵列有2块硬盘损坏离线，RAID5阵列瘫痪，影响下层LUN无奈失常应用。管理员分割咱们数据恢复核心进行数据恢复，硬件工程师检测硬盘没有发现物理故障和坏道。 服务器数据恢复过程：1、备份数据。应用数据恢复工具将所有磁盘镜像备份。 2、剖析RAID构造。故障服务器的LUN都是基于RAID的，须要先剖析底层RAID的信息，再根据剖析获取到的raid相干信息重构原始RAID。通过剖析获知4号盘为hot Spare盘。剖析Oracle数据库页在每个磁盘中的散布状况得出RAID组的条带大小，磁盘程序及数据走向等RAID组的重要信息。 3、剖析RAID掉线盘。利用剖析获取到的RAID信息，通过北亚自主开发的RAID虚构程序将原始的RAID拟进去。仔细分析每一块硬盘中的数据，通过北亚自主开发的RAID校验程序对条带做校验，将最先掉线的硬盘剔除出raid。 4、剖析RAID组中的LUN信息。将RAID最新的状态虚构进去当前剖析LUN在RAID中的分配情况和LUN调配的数据块MAP。只须要将底层6个LUN的数据块散布MAP提取进去，而后针对这些信息编写相应的程序对所有LUN的数据MAP做解析，依据数据MAP导出所有LUN的数据。 5、解析LVM逻辑卷。剖析生成进去的所有LUN，发现所有LUN中均蕴含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息，发现一共有三套LVM：其中一套LVM中划分了一个LV，寄存OA服务器端的数据，另外一套LVM中划分了一个LV，寄存长期备份数据。其余4个LUN组成一套LVM并划分了一个LV，寄存Oracle数据库文件。北亚数据恢复工程师编写解释LVM的程序尝试将每套LVM中的LV卷解释进去，但解释程序出错。 6、修复LVM逻辑卷。仔细分析报错的起因，由开发工程师debug程序出错的地位并由高级文件系统工程师检测复原进去的LUN，检测存储瘫痪是否导致LMV逻辑卷的信息损坏。通过认真检测，发现存储瘫痪的确导致了LVM信息损坏。尝试人工对损坏的区域进行修复，并批改LVM解释程序从新解析LVM逻辑卷。 7、解析VXFS文件系统。搭建HP-Unix环境并将解释进去的LV卷映射到HP-Unix，尝试Mount文件系统。后果Mount文件系统出错，尝试应用“fsck –F vxfs” 命令修复vxfs文件系统，修复实现后还是不能挂载，狐疑底层vxfs文件系统的局部元数据被毁坏，须要进行手工修复。 8、修复VXFS文件系统。仔细分析解析进去的LV，并依据VXFS文件系统的底层构造校验此文件系统是否残缺。通过剖析发现底层VXFS文件系统有问题，起因是存储瘫痪的时候文件系统正在执行IO操作，因而局部文件系统元文件没有更新导致损坏。对这些损坏的元文件进行手工修复让VXFS文件系统可能失常解析。再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统没有报错，胜利挂载。 9、复原所有用户文件。在HP-Unix机器上mount文件系统后将所有用户数据均备份至指定磁盘空间。局部文件目录截图如下： 10、检测数据库文件是否残缺。应用Oracle数据库文件检测工具“dbv”检测每个数据库文件是否残缺，没有发现错误。应用北亚自主研发的Oracle数据库检测工具检测发现有局部数据库文件和日志文件校验不统一，数据库工程师对此类文件进行修复并再次校验，直到所有文件校验齐全通过。 11、启动Oracle数据库。因为咱们数据恢复核心提供的HP-Unix环境没有此版本的Oracle数据库，和用户协调将原始环境带至北亚数据恢复核心，而后将复原进去的Oracle数据库附加到原始生产环境的HP-Unix服务器中并尝试启动Oracle数据库，启动胜利。局部截图如下： 12、数据验证。由用户方配合启动Oracle数据库，启动OA服务端，在本地电脑端装置OA客户端。通过OA客户端对最新的数据记录以及历史数据记录进行验证，并且安顿不同部门人员进行近程验证。最终数据验证无误，数据残缺，数据恢复胜利。 数据恢复论断：因为故障产生后保留现场环境良好，没有做相干危险的操作，对前期的数据恢复有很大的帮忙。整个数据恢复过程中尽管遇到好多技术瓶颈，但也都一一解决。最终在预期的工夫内实现整个数据恢复，复原的数据用户方也相当称心，Oracle数据库服务，OA服务端等所有服务可能失常启动。

服务器数据恢复环境： SUN光纤存储系统；6块硬盘组成RAID6，划分若干LUN，MAP到不同业务的服务器上，服务器运行SUN SOLARIS操作系统。 服务器故障&剖析： 因为业务扩大的须要，用户新增了一台IBM服务器用于新增利用，在光纤存储在线的状态下将存储中的某个LUN映射到新增的IBM服务器中。不料映射的卷原先曾经MAP到SOLARIS生产零碎上的某个LUN上了，IBM服务器对此LUN进行了局部初始化，之后SOLARIS上的磁盘报错，重启后发现卷无奈挂载。用户分割SUN工程师进行检测后，进行了fsck的操作，实现操作后文件系统可挂上，但很多数据失落或大小变为0，尤其最新数据毁坏重大。于是用户分割咱们数据恢复核心进行数据恢复。 SAN环境下此类故障较为常见，少数是人为导致，本案例故障也是如此。失常状况下，SAN调配进去的LUN是采纳独占模式的，如果同时被几个操作系统管制，容易造成写操作不互斥，文件系统一致性出错。 如果要复原此局部数据，须要深刻文件系统查看各构造的毁坏状况。本案例中，文件系统采纳UFS，所以对任何一个须要复原的文件而言，优先思考目录信息、节点、数据区是否失常，如上述3个构造均失常，数据可残缺复原。但少数状况下，fsck后INODE会革除，即便留下目录信息，也无奈与数据一一对应，这时候就只能参考文件外部格局进行类型式的数据恢复了。 服务器数据恢复过程： 1、服务器数据恢复工程师对故障卷做残缺备份，因RAID无故障，所以能够间接在SOLARIS环境中对原LUN进行备份。 2、在备份中剖析文件系统，确定了需复原文件的inode曾经全副革除，无奈还原，所以只好按文件类型进行解决。 3、对用户须要复原的特定文件进行剖析，发现采纳vfs公文零碎的索引文件具备强的类型特色，同时文件中蕴含目录信息。 4、依照公文零碎的索引结构特征，北亚服务器数据恢复工程师写程序提取数据，提取后依据特色重新命名。 5、按类型复原数据文件，而后由用户依据索引文件对数据文件进行重新整理。 6、历时24小时，目录索引文件99%复原胜利，数据文件大部分复原胜利，其余已毁坏无奈复原的文件由用户依据目录索引文件从新向其余部门采集。用户认可本次数据恢复后果。

服务器存储故障：IBM System Storage某型号存储服务器lvm信息失落。调配给aix小机应用的3个卷，lvm信息均已失落，拜访不了。管理员分割咱们数据恢复核心进行数据恢复。 服务器存储数据恢复过程：1、服务器硬盘镜像。为避免数据恢复操作对原始磁盘数据造成二次毁坏，服务器数据恢复工程师对故障服务器中的每块磁盘做镜像备份。后续的所有数据恢复操作在镜像文件上进行。 2、重组raid。raid必备常识：raid条带就是将间断的数据分成很多局部，并别离存储到不同磁盘下来，能够让多个过程同时拜访数据的多个不同局部而不会造成磁盘抵触。除非业务须要必须进行调整外，通常状况下都是通过默认设置由硬件控制器决定。重组raid操作必须要先剖析获取raid条带信息。 服务器数据恢复工程师剖析重组raid后，持续剖析所有数据中的lun分配情况，并通过lun的散布地位和构造复原出服务器中的lun。 针对vg內lv做剖析。如果vg内的lv信息还在，可依据lv信息导出vg内的每个lv。依据aix lvm的调配策略和lv內文件系统的规定，服务器数据恢复工程师去拼接每个lv，在复原的过程当中发现大部分lv都是间断散布的，有多数一部分存在碎片，将这小局部碎片拼接胜利，并将找到的lv导出为镜像文件。 3、复原数据。对存在jfs2文件系统的lv，从底层提取外面的数据文件并导出到windows环境中。 对存在db2表空间、informix表空间的lv，将导出的lv的镜像文件（在windows环境下）用nfs共享给aix小机，而后通过将lv的镜像文件导入到aix中新建的lv中。 导出数据实现后搭建数据库环境，尝试启动数据库，启动数据库胜利。进行文件系统验证，在复原进去的文件中查找用户须要的文件没有发现问题。数据恢复实现。

SqlServer数据库故障&剖析：SQL server数据库的数据无奈被读取。管理员分割咱们数据恢复核心进行数据库数据恢复。数据库数据恢复工程师对故障数据库进行剖析，发现SQL Server数据库文件无奈被读取的起因是因为底层File Record被截断为0，无奈找到文件结尾，数据表构造也被损坏。镜像文件后面80M左右的空间和两头一部分空间被笼罩掉，零碎表损坏，无奈读取，思考用主动备份文件来提取表构造。日志中的操作记录： 因为零碎表被损坏，有大量数据表的构造无奈被确定，只能靠数据库数据恢复工程师依据教训进行复原工作。 数据库数据恢复计划：通过北亚数据库数据恢复工程师团队的会诊，确定以下数据库数据恢复计划：备份用户数据——剖析备份文件中旧数据的数据库——从旧数据库中寻找数据表的构造——从日志中提取一部分数据表的构造——从日志中和残留数据中提取完整的数据——依据日志复原对应的数据，并检查数据是否正确——核查数据没问题后复原所有数据。 SqlServer数据库数据恢复过程：1、备份数据。硬件工程师首先检测硬盘是否存在物理故障。没有发现硬件问题后对每块硬盘做镜像备份。应用业余工具备份所有硬盘数据： 2、扫描镜像文件。用工具关上残留文件并剖析硬盘底层数据，发现硬盘底层中还残留着许多SQL Server的日志和备份文件。残留日志中有很多数据库插入语句的操作记录。残留备份文件中发现建表语句和局部旧数据，尝试提取这些数据。为了放慢数据提取速度，北亚数据恢复工程师编写了一个提取数据库相干数据的小程序，扫描整个硬盘中所有的数据库残留数据，提取所有数据。 3、剖析扫描数据。对扫描到的所有日志文件进行剖析发现日志文件中分数据页，有着固定的结尾和结尾，其中每条数据在固定的地位都有本人的object ID号，在扫描文件中持续搜查有同样object Id的数据记录，发现构造雷同，能够确定这是完整的数据，能够提取。再对扫描到的备份文件进行剖析发现从中能够提取出很多建表语句，获取到一部分表构造。对于残余的表构造，因为截断为0的局部刚好在零碎表，没有方法提取表构造，只能从日志中提取的数据来推断表构造和数据类型。 4、提取数据。依据之前剖析，北亚数据恢复工程师编写程序从备份文件中提取建表语句，依据建表语句剖析出表构造与各种数据类型，同时在残留的零碎表中寻找22H、07H、05H表。依据这些建设表与OBJECT_ID的对应关系编写新的程序对日志中的记录进行提取，依据object ID来对应数据和表，并插入到新表中。 5、验证所有数据。经管理员亲自验证，复原进去的新表与应用业余工具察看到的数据基本一致，本次数据恢复胜利。

服务器数据恢复环境：IBM某型号小型机+AIX+Sybase+某型号存储阵列柜。阵列柜12块SAS机械硬盘组成RAID（其中一块为热备盘）。 服务器故障：一块磁盘呈现故障离线，管理员更换磁盘，开始同步数据，数据同步到一半左右时，另一个磁盘也呈现故障，逻辑盘无奈挂载在小型机上，业务中断。存储管理界面显示两块硬盘故障脱机。其中10号槽位故障硬盘为热备盘，3号槽位故障硬盘状况如下图所示： 存储阵列柜中的2组Mdisk加到一个pool中，次要数据pool无奈加载，其中三个通用卷均无奈挂载，具体情况如下图所示： 管理员分割咱们数据恢复核心进行数据恢复。**服务器数据恢复过程：**1、服务器数据恢复工程师应用工具对其中的10块磁盘做镜像, 用PC3000给故障盘做镜像，所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘数据造成影响。 2、通过北亚服务器数据恢复工程师团队会诊，最初确定了2种数据恢复计划。 数据恢复计划一：对存储进行强制上线操作。1、首先剖析底层数据，找到故障存储中的故障硬盘的离线程序。2、修复后离线的故障硬盘。3、将修复实现的硬盘插回存储进行强制上线操作。 数据恢复计划二：解析存储构造。1、对Mdisk进行剖析和重组。A、依据用户提供的局部配置信息，将硬盘依照Mdisk组分类。B、剖析每一组Mdisk中的所有硬盘获取相干raid信息。C、应用数据恢复软件对Mdisk进行虚构重组。 2、对pool进行剖析。A、剖析所有Mdisk获取到pool的相干信息。B、解析pool在Mdisk上的散布状况。3、LUN构造剖析。A、剖析pool中的条带大小。B、解析LUN位图，剖析各LUN在pool中的散布状况。C、北亚数据恢复工程师编写程序提取LUN。 验证数据&数据移交 ：对生成出的数据进行随机抽样检测，没有大量数据问题。在存储设备上创立与原先环境一样大小数量的LUN，将提取出的数据LUN的镜像文件复制到存储上创立的LUN中，交给用户。数据移交后，用户重新配置存储环境，数据一切正常，本次数据恢复工作圆满完成。

服务器Raid磁盘离线故障：服务器中有一组或多组Mdisk，其中一组Mdisk中有一块硬盘故障离线，热备盘启动并且开始同步数据，如果同组Mdisk中的另一块硬盘也因为故障离线就会导致热备盘同步失败，该组Mdisk生效，从而导致整个卷无奈应用。 服务器Raid数据恢复过程：1、对故障阵列中的每一块磁盘进行镜像备份，前期所有的数据恢复工作将在镜像文件上进行，不影响原始磁盘数据。2、剖析并重组Mdisk，首先依据用户提供的配置信息，把硬盘依照Mdisk组进行分类。剖析每一组Mdisk中的所有硬盘，获取raid相干信息。应用业余的数据恢复软件虚构重组Mdisk。3、剖析所有Mdisk获取到pool的相干信息。应用业余的数据恢复软件虚构重组出pool。4、掉盘剖析。因为raid5最多只能容许一块成员盘离线，raid5解体至多有两块盘产生故障离线。北亚数据恢复工程师对各成员盘中的底层数据进行剖析，发现有两块硬盘前部的数据齐全一样，初步判断这两块盘中一块硬盘为热备盘，另一块硬盘为故障盘。据此能够判断故障状况：raid5中有一块成员盘产生故障离线，热备盘上线开始同步数据，与此同时另一块成员盘也产生故障离线，raid生效。Raid恢复正常时，因为先产生故障的硬盘上的数据曾经不是最新的，所以恢复正常后的raid中的数据呈现局部谬误。5、对硬盘的raid构造与成员盘的掉盘状况剖析实现后，应用业余数据恢复软件实现对Mdisk和pool的组建，并生成其中的数据。 小贴士：服务器磁盘阵列故障后应该怎么做？1、不要自觉强行上线。Offline指示灯亮起，这示意要求更换一个雷同型号的无故障硬盘，并且从新校验算法。RAID磁盘阵列中很可能有不止一个呈现了不稳固景象，服务器的Offline提醒常常会误报或是脱漏其余也存在隐患的硬盘。强制上线过程中硬盘进行大量的读写操作，一旦其它硬盘掉线则数据恢复难度加大。所以在强制上线前要检测每一个硬盘的稳定性，这样才更加保险。 2、爱护好第一现场对于厂商而言，硬件设施修复才是售后服务的次要指标，因而往往为修复硬件设施故障而就义掉数据。北亚数据恢复核心的工程师介绍：用户寻求厂商的售后服务工程师服务而导致数据被彻底毁坏的状况简直每个星期都会产生。厂商的售后服务工程师都偏差于硬件修复，而RAID数据恢复则是以软件类操作为主。此外，即使是简略的测验性操作，也有可能为前期的数据恢复带来不便。当raid硬盘损坏数量超过阵列本身的容错能力时，必须将损坏硬盘的镜像齐全提取能力实现最终的复原。如果频繁对硬盘上电，很容易造成磁头疲劳伤害，甚至划伤盘片。正确的解决办法该当是立刻征询业余的数据恢复服务商。 3、抉择业余正规的数据恢复核心在抉择数据恢复服务商时，公司规模、技术教训、工程师团队、业界内的口碑都是须要考量的重要指标。

服务器存储raid数据恢复环境：华为OceanStor某型号存储，16块FC硬盘（蕴含一块热备盘）组成RAID5。 服务器存储raid故障：该存储RAID5中的一块硬盘因为未知起因离线，热备盘上线同步数据，同步实现一半左右时另外一块硬盘未知起因离线，数据同步失败，raid5解体，下层的lun生效。管理员分割咱们数据恢复核心对该存储中的raid5进行数据恢复。 服务器存储raid数据恢复过程：1、检测raid5中所有磁盘：北亚硬件工程师首先对故障raid中所有磁盘进行物理故障检测，检测后果为第一块掉线硬盘存在物理故障，其余的包含前面掉线的硬盘均无物理故障。 2、备份raid5中所有磁盘：将raid5中所有磁盘都镜像备份，后续的数据恢复操作都在镜像文件中进行，防止可能对原始数据造成的二次毁坏。 3、剖析raid5构造：数据恢复工程师对故障raid中的所有磁盘进行剖析，找出热备盘（热备盘与其余数据盘有显著区别）。因为raid是条带化的，raid中的数据是依照肯定法则存储，通过剖析raid中的数据库页在每一个物理磁盘中的散布状况，北亚数据恢复工程师计算出raid的磁盘程序、数据走向、条带大小等根本信息。 4、找出raid5中被同步的坏盘：依据剖析获取到的RAID信息，尝试通过北亚自主开发的RAID虚构重组程序将原始RAID虚构重组进去。故障RAID中掉线两块盘并且有一块硬盘中的数据因为同步失败损坏，数据恢复工程师仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其余硬盘显著不一样，因而初步判断此硬盘是被同步损坏的硬盘。通过北亚自主开发的RAID校验程序对这个条带进行校验，最终确定那块被同步损坏的硬盘。 5、剖析raid中的lun信息：剖析lun在故障raid中的调配状态和lun调配的数据块，而后依据数据MAP导出LUN的数据。 6、解析EXT3文件系统：因为是应用热备盘虚构重组的RAID，EXT3文件系统无奈失常挂载，只能提取出oracle数据库文件。利用北亚自主开发的文件系统解析程序对其进行文件系统解析并导出oracle数据库文件，而后把数据库文件移交给数据库复原工程师进行校验和验证。 7、修复数据库，检测数据文件完整性：应用Oracle数据库文件检测工具检测每个数据库文件的完整性然而发现错误。于是应用北亚自主研发的Oracle数据库检测工具进行检测，发现局部数据库文件和日志文件谬误， system和sysaux表空间存在许多坏块，管制文件全副损坏，eschoolspace表空间的文件的坏块更多，undotbs02失落；北亚数据库数据恢复工程师对这些文件进行手工修复。 北亚数据库数据恢复工程师创立管制文件、undo表空间，启动数据库到mount。因为system数据文件存在坏块，数据库不能open，各种隐含参数也不能绕过system的坏块。搭建数据库环境并应用dmp文件还原数据库，最终导入10G左右的数据。 数据验证：由用户方配合启动Oracle数据库，在本地虚拟机装置OA客户端，通过OA客户端对数据记录进行验证，并且让用户安顿不同部门人员进行近程验证。验证通过，数据恢复胜利。

服务器数据恢复环境： HP StorageWorks系列服务器；VMWARE ESX虚拟主机平台，VMFS文件系统；8块硬盘组成RAID5，1块热备盘。 服务器故障： 服务器在失常运行中两块硬盘指示灯显示黄色，经服务器管理员检测发现这2块硬盘体现为：无奈读取序列号，在SAS扩展卡上无奈辨认，须要对raid进行数据恢复。管理员分割咱们数据恢复核心进行服务器raid数据恢复。 服务器数据恢复过程： 1、硬盘物理故障修复。 首先须要确定该组raid的磁盘掉线起因。硬件工程师在接到故障服务器后将2块故障盘连贯到内部的SAS扩展卡上加电检测，发现磁头不寻道。硬件工程师将PCB拆散后查看硬盘HDA组件，发现有局部氧化，对氧化部位进行清洁后再次加电检测发现磁头依然不寻道。于是硬件工程师只能对故障硬盘进行收盘修复。 硬件工程师将失常的热备盘收盘拆取PCB替换掉故障盘的PCB，再将故障盘PCB上的ROM芯片拆取装置到新PCB上进行修复。故障硬盘硬件修复实现后再次进行检测能够失常起转，磁头寻道声音失常，然而敲盘声音显著。硬件工程师另找磁头进行更换，硬盘能够失常辨认，故障盘数据镜像胜利。 2、重组RAID5。 应用工具关上7块磁盘发现所有硬盘的0扇区都有“55 AA”标记，0x01C2H处示意该分区的类型，这里显示“05”，代表这是一个扩大分区。因而从0扇区看这是一个不失常的MBR分区构造。依照这一办法持续查找，别离在7号盘和8号盘找到了“55 AA”的标记。8号盘查问后果如下图。这是一个失常的MBR分区，其0x01C6处数值代表指向的下一个扇区为GPT的头部。 7号盘查问后果如下图。其0x01C6处数值代表指向下一个扇区。然而下一个扇区很显著不是GPT的头部。 由此能够初步判断8号盘是第一块盘，7号盘可能是最初一块盘。GPT分区所在扇区起始于172032扇区，因而初步确定LUN的起始扇区是172032扇区。 raid小常识：条带也就是raid阵列块，它是RAID解决数据的根本单元。不同的RAID阵列的条带大小也各不相同。RAID5的1个条带组中有1个校验区，依据这个法则能够对该raid5进行剖析。咱们能够通过比较法确定条带大小：如某一条带组中的校验区跟这一条带组中的非校验区可能相差的很显著，通过工具查看并做比照就能够找到条带大小。 服务器数据恢复工程师对该服务器raid进行剖析搞清楚条带大小为1024个扇区。依照1024扇区宰割，使一个记录为一个条带的大小，如下图所示，7块盘跳到同一记录283123。 当7块盘都定位到同一地位时，通过比照能够判断校验区的走向，继而判断整个RAID5的走向。之前曾经判断出8号盘是第一块盘，把8号盘放在第一个地位，确定RAID5为左走向，盘序为8，2，3，4，1，7，5。 服务器数据恢复工程师初步确定LUN的起始扇区是172032扇区，应用数据恢复工具跳到172032扇区对硬盘的应用状况进行查看，失常状况下这个扇区所属条带中的5号盘应该是校验区，但实际上却显示校验区为8号盘。依据该raid左走向的法则，5号盘的校验区应该在172032-1024=171008扇区，即上一个条带。跳转到171008扇区，北亚服务器数据恢复工程师发现校验区为5号盘。因而能够确定LUN的起始扇区为171008扇区。 应用raid重组工具依照确定的盘序重组raid增加进去，如下图所示。抉择RAID5，Stripe size 512KB，左异步。 点击Build进行重组。组好RAID后，因为数据从1024*8=8192个扇区开始。如果工具没有跳转到此扇区的性能，那么刚组好的RAID必须和一个文件再进行一次Build重组操作。RAID的起始扇区(Start sectors)抉择8192，这个文件能够任意抉择起始扇区和大小(Count sectors)，下图为重组后的raid5。 服务器数据恢复后果验证： RAID5磁盘阵列重建实现后经由服务器管理员亲自验证，验证通过，服务器数据恢复实现。

数据库数据恢复环境：某品牌服务器存储有2组raid，一组raid1（2块硬盘），一组raid5（5块硬盘）；寄存有SqlServer数据库。 数据库故障：寄存SqlServer数据库的分区因为数据量减少而导致原来划分的空间有余，管理员在另外一个分区中生成了一个.ndf文件并将数据库门路指向这个分区持续应用，一段时间后数据库呈现故障报错，提醒连贯生效，SqlServer数据库无奈附加查问。管理员于是进行尝试性数据恢复操作没有胜利复原数据，于是分割咱们数据恢复核心进行数据恢复。 数据库数据恢复过程：1、备份数据。服务器数据恢复工程师将故障服务器存储的所有磁盘都镜像备份。 2、数据库故障剖析。因为SqlServer数据库文件所在磁盘分区空间有余，数据库无奈失常运行，呈现逻辑谬误。剖析存储中RAID1和RAID5的构造，依据获取到的raid信息别离虚构重组出RAID1和RAID5并查看其中数据。 因为在数据库产生故障之后，管理员尝试过屡次在原环境复原数据库的数据，原始数据库文件被更改、笼罩，磁盘空间被多次重复擦除写入，所以无奈应用管理员屡次尝试复原之后的数据库文件进行修复。 好在管理员在数据库产生故障，尝试进行复原之前备份过一份数据库文件。 3、数据库修复。将之前备份的数据库文件尝试在数据库中附加，后果附加失败，谬误提醒如下： 谬误提醒主数据库文件和次级数据库文件不匹配，数据库数据恢复工程师查看.ndf文件底层，发现.ndf文件中简直没有数据。尝试勾销.mdf文件和.ndf文件之间关联，只用.mdf文件进行附加依然呈现谬误提醒： 谬误提醒日志文件（.ldf）和数据库文件（.mdf）不匹配。 于是数据库数据恢复工程师尝试对数据库进行无数据库附加，附加胜利。然而发现数据库系统表损坏，无奈失常应用。 数据库数据恢复工程师对数据库的零碎表尝试修复，然而零碎表损坏重大无奈修复。 解析数据库文件中的数据库记录，北亚数据恢复工程师编写相应的程序提取数据库文件中的数据库记录，剖析数据库备份获取数据库中的表构造，重构表构造并把提取出的数据库记录导入到新的表中。 数据验证：由管理员对提取出的数据库记录进行验证，确认所有数据完全恢复。顺便揭示一下大家，在数据库的应用过程中，要正当调配数据库文件所在磁盘的空间，及时清理垃圾数据，保障数据库的失常、平安运行。

虚拟机数据恢复环境：Dell某型号服务器用RAID卡+4块STAT硬盘组成RAID10；XenServer虚拟化零碎，虚拟机操作系统是Windows Server；两个虚拟机磁盘（系统盘 + 数据盘）；Web服务器（ASP + SQL的网站架构）。 虚拟机故障&剖析：服务器忽然断电导致XenServer服务器中一台XenServer虚拟机不可用，虚构磁盘文件失落。服务器管理员分割咱们数据恢复核心进行虚拟机数据恢复。服务器数据恢复工程师首先将故障服务器上的硬盘连贯到数据恢复服务器上对数据进行镜像备份。通过镜像文件剖析底层数据发现故障服务器中每个XenServer虚拟机的虚构磁盘都是一个LV，虚构磁盘模式是精简模式。LVM的相干信息在XenServer中都有记录，查看LVM的相干信息发现并没有损坏的虚构磁盘信息，初步判断LVM的信息曾经被更新。再次对底层进行剖析还是找到了未更新的LVM信息。如下图： 依据未被更新的LVM信息找到虚构磁盘的数据区域，然而该区域的数据已被毁坏。最终能够确定虚拟机不可用的起因是虚拟机的虚构磁盘被毁坏，虚拟机中的操作系统和数据失落，而呈现这种状况很可能是虚拟机遭逢网络攻击或hack入侵后留下的恶意程序造成的。认真核查这片区域后，服务器数据恢复工程师发现尽管该区域很多数据被毁坏了，但发现了很多数据库的页碎片，能够尝试将数据库的页碎片拼接成可用的数据库。 虚拟机数据恢复过程：1、复原计划一依据RAR压缩包的构造找到压缩包的数据开始地位，RAR压缩包文件的第一个扇区中会记录此RAR的文件名。服务器数据恢复工程师通过匹配备份数据库的压缩包文件名和目前找到的压缩包地位的文件名，即可找到备份数据库压缩包的开始地位。找到压缩包的地位后剖析这片区域的数据，将此区域的数据恢复进去并重命名为一个RAR格局的压缩文件。尝试解压此压缩包，解压报错如下图所示： 剖析复原进去的压缩包，服务器数据恢复工程师发现其中有局部数据损坏。应用RAR修复工具修复后解压出局部数据，后果解压进去的数据只有网站的局部代码，并没有发现数据库的备份文件。初步判断RAR压缩包中数据库的备份文件是损坏的。下图是解压进去的局部网站代码： 2、复原计划二因为计划一并没有将数据库复原进去，服务器数据恢复工程师采纳计划二复原数据库。依据SQL Server数据库的构造去底层剖析数据库的开始地位。在服务器管理员获取到数据库名称之后，数据恢复工程师剖析底层找到此数据库的开始地位。SQL Server数据库的每个页都会记录数据库页编号以及文件号，北亚数据恢复工程师依据SQL Server数据库的这些特色编写程序去底层扫描合乎数据库页的数据。而后将扫描进去的碎片按程序重组成一个残缺MDF文件，再通过MDF校验程序检测这个MDF文件是否残缺。重组的MDF文件：  验证数据：MDF校验程序检测没问题后搭建数据库环境。将重组后的数据库附加到搭建好的数据库环境中并查问相干表数据是否失常，查问最新数据是否存在。 因为数据库须要联合网站代码能力更精确验证数据库的完整性。用网站代码搭建好环境，而后将复原好的数据库配置好进行验证。经用户亲自验证后最终确认数据库没问题，本次数据恢复胜利。

服务器存储数据恢复环境：HP EVA某型号存储；6块SAS硬盘组成raid5阵列；WINDOWS SERVER操作系统。 服务器存储故障&剖析： 在失常工作状态下遭逢两次意外断电，管理员将服务器存储重启，raid提醒“无奈找到存储设备”，进入raid治理模块进行查看时死机，屡次重启进入raid治理模块故障仍旧，管理员分割咱们数据恢复核心进行服务器数据恢复。 咱们数据恢复工程师常常会遇到因为意外断电而导致的raid模块硬件损坏或者riad治理信息失落等导致的数据失落的状况。失常状况下，raid一旦创立实现后就不再对治理模块中的信息进行更改，不过因为raid治理模块信息是可批改信息，一次或屡次意外断电可能导致raid治理模块信息被篡改或失落，情况严重可能导致raid卡元器损坏，导致服务器对多块物理硬盘进行RAID治理的中间层模块不可用。本案例的服务器存储故障就属于这种状况。 服务器数据恢复过程： 1、服务器数据恢复工程师首先将服务器中的所有硬盘进行物理检测，服务器所有硬盘均可失常读取。对服务器所有硬盘进行镜像备份。 2、对镜像文件进行数据分析，通过故障存储的文件系统存储规定剖析北亚服务器数据恢复工程师获取该服务器存储中6块硬盘的数据块大小、条带信息、盘序、校验形式等信息，在虚拟环境中重建虚构raid。 3、对所构建RAID中的数据进行逻辑校验，确保重构进去的RAID利用的各项参数正确无误，而后对服务器管理员最为关注的数据进行齐全验证。 4、管理员确认数据恢复后果没有问题后，将所有复原进去的数据迁徙至管理员提前准备好的存储环境中，数据恢复实现。 服务器存储数据安全小贴士： 1、尽量保障机房电源供给稳固，以缩小供电异样对服务器及存储的挫伤。 2、最好为重要的服务器及存储配置UPS，可在机房意外断电的状况下保障外围业务零碎能持续维持一段时间的失常工作，从而为启动应急解决方案博得贵重的工夫。 3、对于服务年限已久的服务器应定期平安情况查看，对整体运行状态进行评估以决定是否进行硬件及零碎的全面降级，同时提前制订突发数据劫难的应急解决计划，以升高数据劫难带来的损失。

服务器数据恢复环境： IBM某型号服务器，装置VMware虚拟主机；柏科某系列存储，寄存虚拟机文件；VMware ESXi 5.5版本操作系统；虚拟机操作系统：Windows Server 2008；SQL Server 2008数据库服务器，治理宏桥和索菲两套利用数据库；虚构磁盘：200G数据盘（精简模式）+ 160G快照数据盘。 服务器故障&剖析： 意外断电导致某台虚拟机不能失常启动，通过查看发现此虚拟机除了磁盘文件以外其余配置文件全副失落，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。管理员征询VMware工程师后尝试新建一个虚拟机，但发现ESXi存储空间有余，于是将故障虚拟机下的xxx-flat.vmdk磁盘文件删除开释空间，从新建了一个虚拟机并调配了固定大小的虚构磁盘。然而问题仍旧没有解决，数据失落。管理员分割咱们数据恢复核心进行数据恢复。 备份数据。服务器数据恢复工程师在VMware vSphere Client上将挂载的存储中VMFS卷以失常形式卸载掉。而后将存储上的VMFS卷通过网线的形式连贯到备份服务器上，应用业余工具将整个VMFS卷以扇区的形式镜像到已筹备好的备份空间，之后的剖析和数据恢复操作均在镜像文件上进行。 剖析故障起因。通过剖析VMFS卷的底层数据发现，ESXi主机的忽然断电导致故障虚拟机目录下的目录项被毁坏，这种毁坏还不会影响到虚拟机的重要数据，能够通过人工进行修复。如果人为删除某个文件的话，则目录项对应的数据区索引会被清掉，也不会影响删除文件的理论数据。这种状况可依据删除虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终复原删除的虚构磁盘文件。然而在上述的两种状况之下又新建了一台虚拟机并且调配了虚构磁盘，通过剖析发现这个新建的虚拟机所占用的磁盘空间全副被清零。 如果新虚构磁盘占用了删除虚拟机磁盘所开释的空间，那么此局部空间将无奈复原。 故障虚拟机的目录项区域： 服务器数据恢复计划： 通过北亚数据恢复工程师团队的会诊，最终确定三个数据恢复计划。 1、数据恢复计划一：复原删除的VMDK文件。依据删除虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在VMFS卷的自由空间中进行碎片匹配和合并，最终复原删除的虚构磁盘文件。再利用快照合并程序将快照文件和复原的虚构磁盘文件合并成一个残缺的虚构磁盘文件，而后利用业余的文件系统解释工具解释虚构磁盘文件中的所有文件。 2、数据恢复计划二：复原MSSQL数据库文件。如果计划一施行成果不现实，能够依据SQL Server数据库文件的构造对VMFS卷自由空间中合乎SQL Server页构造的数据区域进行统计、剖析和聚合，最终生成一个能够失常应用的.MDF格局的文件。 3、数据恢复计划三：复原MSSQL数据库备份文件。本案例中的数据库每天都在做一次增量备份，15天做一次齐全备份。如果计划一和计划二施行后还有一些数据库数据无奈复原，则只能通过复原备份文件来复原数据库了。依据备份文件.bak的构造对VMFS卷自由空间中合乎SQL Server备份文件构造的数据区域进行统计、剖析和聚合，最终生成一个能够失常导入到SQL Server数据库中的.BAK格局的文件。 服务器数据恢复过程： 1、实施方案一。 依据VMFS卷的构造以及删除虚构磁盘的文件系统信息，在底层的自由空间中扫描合乎删除虚拟机磁盘的区域并统计其数量和大小是否合乎删除虚构磁盘的大小，再依据虚构磁盘中的文件系统的信息将这些扫描到的碎片进行排列组合，后果发现两头有好多碎片缺失。再对这些缺失的碎片进行从新扫描发现这些碎片的确找不到。将扫描到的碎片依照虚构磁盘本来的程序重组，对于没有找到的碎片暂且留空。利用虚构磁盘快照程序将重组好的父盘和快照盘进行合并生成一个新的虚构磁盘，再用业余工具解释虚构磁盘中的文件系统。因为好多数据缺失，文件系统解释过程中频繁报错，提醒某些文件损坏。 在解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录构造失常。尝试将备份导入到数据库中时，数据库导入程序提醒报错。 导入.BAK文件报错信息如下: 2、实施方案二。 因为计划一中并没有将原始的数据库文件复原进去，并且其中很多备份文件都无奈失常应用。因而数据恢复工程师采纳第二套计划来复原尚未复原进去的数据库文件。依据SQL Server数据库的构造去自由空间中找到数据库的开始地位。依据本案例中的数据库构造，数据库的第9个页会记录本数据库的数据库名，依据这个特色能够核查此数据库的头部页是否是正在查找的。数据库的每个页中都会记录数据库页编号以及文件号，北亚数据恢复工程师依据这些特色编写数据库扫描程序去底层扫描所有合乎数据库页的数据碎片，接着将扫描进去的碎片按程序重组成一个残缺MDF文件，再通过MDF校验程序检测整个MDF文件是否残缺。在校验过程中，发现只有2个文件有局部碎片没有找到，其余数据库文件均校验胜利。 其中一个文件中某个碎片失落的区域： 3、实施方案三。 计划一和计划二施行后并没有将所有的数据库文件全副复原进去，有2个文件因缺失局部页导致其无奈失常应用。因而须要利用备份来复原这两个数据库文件。然而在查看完这两个文件的备份后发现其中一个文件的全副备份因备份机制故障没有备份进去，而另外一个文件的全副备份则没有，只有全副增量备份。 因为其中一个文件只缺失大量的页，能够依据缺失的页号在增量备份中查找，再将找到的页补到这个文件中，服务器数据恢复工程师通过这个办法复原出一部分失落的数据库页。然而补完后发现还是缺失局部页，无奈失常应用。服务器数据恢复工程师只好通过北亚自主开发的数据库解析程序将这个文件中比拟重要的几十张表胜利导出，并导入到新建的数据库中。 验证数据： 在本地服务器中搭建和原始环境一样的数据库环境（SQL Server 2008），管理员通过近程工具连贯到验证服务器并装置层宏桥应用软件，由用户方工程师验证数据库是否残缺，通过认真的验证后数据库根本没有问题，下层利用能够失常运行，数据记录也根本没有缺失，数据恢复胜利。

服务器数据恢复环境： 华为某型号服务器；10块硬盘组成raid6；EXT3文件系统，划分2个lun。 服务器故障&剖析： 服务器在工作过程中raid6瘫痪不可用，管理员对故障服务器的raid进行从新搭建的操作并且初始化raid，初始化进行到40%左右时强行进行了初始化，局部数据曾经受到严重破坏。管理员在多家数据恢复公司数据恢复失败之后分割到咱们数据恢复核心。 导致服务器失落数据的起因是raid6瘫痪，管理员随后应用原raid6中的9块硬盘搭建riad5并进行了长时间的初始化，这种操作对原始数据造成不可逆的损坏。在起初的服务器数据恢复操作过程中也证实了第二个LUN能够应用惯例的RAID6数据恢复办法复原出数据，但寄存重要数据的第一个lun中的数据恢复胜利的可能性极低。在咱们数据恢复核心接到故障服务器之前曾经有多家数据恢复公司对故障服务器进行了数据恢复操作，但均未能胜利复原出须要的重要数据。 服务器数据恢复过程： 1、对故障服务器中的所有磁盘进行镜像备份。 2、服务器数据恢复工程师剖析故障服务器中原RAID6的RAID和磁盘的组织构造，再剖析新搭建的RAID5的RAID和磁盘的组织构造。在进行实际操作时因为从新搭建RAID5导致RAID6和RAID5的底层信息大量重合，对这些数据进行剖析辨别十分艰难，服务数据恢复工程师破费很长时间进行剖析辨别。 3、服务器数据恢复工程师通过剖析获取到原raid6和新搭建的raid5信息后进行数据恢复算法的钻研，发现能够通过其余形式复原服务器原始的数据。服务器数据恢复工程师编写程序和校对算法，将服务器中原raid6中的第一和第二个LUN别离镜像到搭好的两个存储上。 4、复原服务器数据。服务器数据恢复工程师验证第二个LUN数据齐全失常，但第一个LUN中被毁坏的一小部分数据极其重要。EXT3的根目录和第一个块组的I节点全在这部分数据外面，服务器数据恢复工程师尝试几款罕用的数据恢复软件进行扫描复原，但成果都不现实，预计前几家数据恢复公司没有胜利复原进去数据的起因就在于此。 5、在这种状况下服务器数据恢复工程师对损坏的EXT3文件系统进行修复。北亚服务器数据恢复工程师编一个小程序对EXT3文件系统进行孤目录查找，重建根目录和I节点，用文件系统解析程序关上齐全失常，但为了保障原始数据的权限和属性，在LINUX下进行简略修复，LINUX能够失常挂载，而后从LINUX中把文件拷贝到格式化为EXT3 的单块磁盘的分区上。这样用户应用数据时，不再须要任何设置，文件目录构造和属性都和原来截然不同。本次数据恢复实现，数据可用性100%。 服务器Raid呈现故障后的数据保护倡议： 1、切忌硬盘再次受到磕碰，服务器中任何一块硬盘对于数据恢复来说都至关重要，如果要害硬盘呈现重大物理损坏，数据恢复工作将变的异样艰巨甚至无奈实现。 2、切忌从新创立raid或者强制online/rebuild，若服务器中有提前离线硬盘或上线同步抉择谬误，会导致数据恢复成果和后果无奈意料。 3、切忌非专业人士对故障存储的次要模块进行装配、更换等操作，不当的操作会对服务器外部数据造成影响，甚至永久性毁坏服务器数据。

服务器数据恢复环境：某品牌存储中12块SAS硬盘组成RAID6，分成一个卷，调配给几台Vmware ESXI主机做共享存储；卷中寄存肯定数量的Windows虚拟机，数据盘都是精简模式。 服务器存储故障：机房断电后开机存储不可用。通过管理员检测诊断后初步判断是断电导致的存储阵列瘫痪。服务器管理员分割咱们数据恢复核心进行数据恢复。 服务器存储数据恢复过程：1、服务器数据恢复工程师将故障存储的所有磁盘连贯到一台Windows Server服务器上，故障磁盘都设为脱机（只读）状态，连贯状态如下图所示：(图中HD1-HD12为指标备份磁盘，HD13-HD24为源故障磁盘)： 2、应用工具以底层形式读取HD13-HD24的扇区时发现了大量扇区损坏，初步判断这种硬盘的读取机制比拟独特。尝试更换操作主机、HBA卡、扩大柜和操作系统，但均呈现雷同故障。与服务器管理员沟通后得悉此控制器对磁盘其实没有特殊要求。 3、应用业余工具对硬盘损坏扇区的散布法则进行检测，后果发现：a、损坏扇区散布以256个扇区为单位。b、除损坏扇区片段的起始地位不固定外，前面的损坏扇区都是以2816个扇区为距离。所有磁盘的损坏扇区散布如下表（只列出前3个损坏扇区）： 北亚服务器数据恢复工程师长期编写小程序，跳过每块磁盘的损坏扇区，镜像完所有磁盘的数据。 服务器存储故障剖析： 1、剖析损坏扇区。剖析损坏扇区发现损坏扇区呈规律性呈现：每段损坏扇区区域大小总为256；损坏扇区散布为固定区域，每跳过11个256扇区遇到一个坏的256扇区；损坏扇区的地位始终存在于RAID的P校验或Q校验区域；所有硬盘中只有10号盘中有一个天然坏道。 2、剖析分区大小。对HD13、HD23、HD24的0-2扇区做剖析，后果发现分区大小和控制器中保留的RAID信息区域大小吻合。依据物理硬盘底层的体现发现原存储并未启用存储中罕用的DA技术(520字节扇区）。分区大小如下图(GPT分区表项底层体现，涂色局部示意分区大小，单位512字节扇区，64bit)： 3、重组RAID： a、剖析RAID构造。存储应用的是规范的RAID6，只须要获取到RAID中硬盘数量以及RAID的走向就能够重组RAID。 b、剖析RAID条带大小。整个存储被分成一个卷调配给几台ESXI做共享存储。卷的文件系统是VMFS文件系统，而VMFS卷中又有寄存了大量的Windows虚拟机。Windows虚拟机中大多应用的是NTFS文件系统，因而能够依据NTFS中的MFT的程序剖析出RAID条带的大小以及RAID的走向。 c、剖析RAID是否存在掉线盘。镜像完所有磁盘后发现最初一块硬盘中并没有像其余硬盘一样有大量的坏道，其中有大量未损坏扇区，这些未损坏扇区大多是全0扇区，因而能够判断这块硬盘是热备盘。 d、重组RAID依据剖析获取到的RAID信息重组RAID，重组后能看到目录构造，然而不确定是否为最新状态。服务器数据恢复工程师随机检测了几个虚拟机发现局部虚拟机失常，初步判断RAID中存在掉线的磁盘。顺次将RAID中的每一块磁盘踢掉，而后查看方才数据异样的中央但并没有发现问题。仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统上。VMFS文件系统如果大于16TB的话会存在一些其余的记录信息，因而在组建RAID的时候须要跳过这些记录信息。再次重组RAID后针对其中的一台虚拟机做验证，发现将所有磁盘退出RIAD后这台虚拟机是能够启动的，但在缺盘的状况下启动就有问题，因而能够判断RAID不缺盘的状态为最佳。 4、验证数据： a、验证虚拟机。对较为重要的虚拟机做验证，发现虚拟机大多能够开机进入登录界面；局部虚拟机开机蓝屏或开机检测磁盘，应用光盘修复后都能够启动。局部虚拟机开机如下： b、验证数据库。对重要虚拟机中的数据库做验证没有发现问题，除了其中一个数据库短少局部数据。通过认真核查后发现这些数据在数据库中原本就不存在。通过查问master数据库中的零碎视图，查出原来的所有数据库信息如下： c、检测整个VMFS卷是否残缺。因为虚拟机数量很多，如果每台都去做验证所破费工夫太长。咱们对整个VMFS卷做检测发现局部虚拟机或虚拟机的文件被毁坏，列表如下： 5、复原数据： a、服务器数据恢复工程师和管理员沟通了目前数据恢复的状况。管理员对几台重要的虚拟机进行验证后，用户反馈复原进去的数据没有问题。数据恢复工程师立刻着手复原所有数据。 b、筹备好指标阵列，将重组的RAID数据镜像到指标阵列上。而后利用工具解析整个VMFS文件系统。因为局部虚拟机的数据盘很大但数据很少，能够间接导出数据而后新建一个虚构磁盘，最初将导出的数据拷贝至新建的虚构磁盘中即可。 c、通过上述办法将复原进去的虚拟机一台一台的复原到用户的ESXI中。后续的数据迁徙过程中由北亚数据恢复工程师和用户方工程师配合实现，这里就不赘述了。 数据恢复后果： 本案例存储故障是由坏道引起的，最终复原进去的数据也有局部损坏，但不影响整体数据，最终的后果也在承受范畴内。

服务器数据恢复环境：某品牌ProLiant某型号服务器； 三块SAS硬盘组成raid；D分区寄存数据库，E分区寄存备份文件。 服务器故障：硬盘故障导致RAID瘫痪，其中一块硬盘状态指示灯显示红色。D分区辨认不进去，E分区可辨认，然而外面的备份文件拷贝不进去，拷贝报错。管理员进行服务器重启操作，离线的硬盘上线并同步数据，然而没有同步完数据就强制关机了，之后服务器没有开启过。管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、服务器数据恢复工程师对服务器中所有硬盘做只读镜像备份，三块SAS硬盘都能够失常读取，通过检测没有发现坏道。 2、服务器数据恢复工程师对镜像文件进行剖析，依据剖析获取到的raid信息重组raid构造并进行异或校验，后果只有局部校验通过。因为离线硬盘上线之后进行的数据同步操作会损坏数据，局部校检通过意味着数据有损坏。 3、尝试多种硬盘离线状态下提取数据，每块硬盘离线所提取的数据都是一样的。 4、服务器数据恢复工程师针对E分区中的dat文件进行剖析，发现两个备份文件都有损坏。 5、服务器数据恢复工程师剖析聚合dat碎片，验证dat数据完整性，后果发现底层构造有损坏。 6、进行D分区数据文件的剖析扫描，因为存储同步，数据文件目录不可见。 7、对D分区自在空间数据页进行扫描，对文件碎片进行剖析和聚合并验证数据文件碎片的完整性和有效性。提取备份文件中的数据记录到新建的数据库中。 8、通过下层利用连贯数据库验证数据的可用性，数据库文件能够失常加载，下层应用软件中的用户账号失常，能够进行失常数据查问。 9、在数据恢复过程中，E盘中发现2个SealLib数据库的备份文件页构造有小局部损坏；在D分区扫描进去的数据碎片中发现比拟间断可用的数据片段。通过对D分区扫描进去的碎片和E分区备份文件进行整合拼接，最终北亚数据恢复工程师修复&解析进去的数据曾经能够撑持下层利用的失常应用。本次数据恢复实现。

服务器数据恢复环境： DroboPro FS网络存储器；8块单盘容量2TB的SAS硬盘组成raid5磁盘阵列。 服务器故障： 服务器运行过程中因为未知起因一个共享文件夹失落，管理员分割咱们数据恢复核心，要求服务器数据恢复工程师到现场进行数据恢复。 服务器数据恢复过程： 1、服务器数据恢复工程师达到现场后对故障服务器存储进行初检。 2、备份数据。把故障服务器存储所有数据进行镜像备份，所有数据恢复操作都在镜像文件上进行。 3、通过对镜像文件的检测剖析，服务器数据恢复工程师初步判断该共享文件夹失落的起因是服务器存储底层零碎谬误。 4、服务器存储构造测试。在征得管理员的批准后，服务器数据恢复工程师对故障服务器存储的存储构造进行测试。测试结果表明该存储应用的是ext4文件系统，固定治理空间为16T，在下层又应用其余构造对ext4文件系统进行治理，图为服务器存储中管理文件构造的ext4文件系统的超级块构造： 5、剖析原始数据。对服务器存储中的原始数据进行剖析，首先查看底层ext4文件系统的完整性。经剖析发现所失落共享文件夹局部构造残缺，但还有局部节点索引失落。 6、因为该服务器存储构造较简单，应用多层索引构造对整体空间进行治理，北亚数据恢复工程师破费大量的工夫对该服务器存储的构造细节进行测试与钻研，终于搞清楚该故障服务器存储中的构造，编写程序对文件系统进行修复并提取数据。 7、因为故障服务器存储中的ext4文件系统中有局部节点索引损坏，最终复原进去的数据残缺度没有达到100%，通过管理员亲自检测之后，重要数据基本上都复原进去，只有极少局部数据无奈复原，必定了本次数据恢复后果。

存储数据恢复环境：IBM某型号存储设备，一个存储机头+多个存储扩大柜；创立多组RAID5。 存储故障：其中一个存储扩大柜中的RAID5由15块硬盘+1块热备硬盘组成。该存储扩大柜中的一块硬盘离线，热备盘替换上线开始同步数据。在热备盘同步数据过程中，另外一块硬盘故障离线，导致数据同步失败，RAID5阵列解体不可用，卷无奈挂载拜访。管理员分割咱们数据恢复核心进行数据恢复。 存储数据恢复过程：1、服务器数据恢复工程师拿到硬盘后为每块硬盘做镜像, 所有的数据恢复操作都在镜像盘上进行, 不会对原始硬盘上的数据造成影响。2、剖析raid构造，利用北亚自主研发的工具虚构重组出lun并提取进去。3、重做故障raid，新创建lun映射到数据恢复服务器，将提取进去的lun文件一一对应拷贝到新创建的lun中。4、将拷贝好lun文件的lun全副映射回原服务器，映射胜利并检测无误。然而管理员验证后发现有局部目录没有复原进去。5、服务器数据恢复工程师通过仔细检查后发现其中一个lun的局部数据错乱，于是从新提取这个lun的数据。6、从新提取实现这个出问题的lun的数据后，再次映射回原服务器。管理员再次对数据进行验证没有发现问题。本次数据恢复胜利。

服务器数据恢复环境：Linux操作系统服务器；EXT4文件系统，KVM虚拟机。 服务器故障：实习生误操作将服务器上的KVM虚拟机删除。该服务器上每台虚拟机蕴含一个qcow2格式文件和一个raw格局的文件，管理员分割咱们数据恢复核心要求复原raw格局的文件。 服务器虚拟机数据恢复过程：1、服务器数据恢复工程师拿到硬盘后对所有硬盘进行镜像备份；2、对服务器中的EXT4文件系统进行，定位被删除的虚拟机文件的节点地位，获取文件残留的索引信息；3、校验残留索引信息是否正确，北亚数据恢复工程师手动修复毁坏不重大的索引；下图为获取的索引等信息： 4、实现修复后北亚数据恢复工程师对服务器中残留的各级索引进行解析，从虚拟机所在的卷中提取虚构磁盘文件；5、依据虚构磁盘文件的提取状况，获取卷中未被索引到的自由空间；6、校验提取出的磁盘文件是否正确和残缺；7、从自由空间中获取无效信息，北亚数据恢复工程师尝试对虚构磁盘文件（如节点，目录项，数据库页等信息）进行修补；下图为提取出的自由空间： 8、因为索引失落，提取出的虚构磁盘文件并不残缺。针对数据库文件失落这种状况，能够从自由空间中获取数据库页去对数据库文件进行修补，但因为局部页所在区域被笼罩，只能尽可能的去补页；9、对于寄存程序代码的服务器中的节点和目录项失落的状况，若节点或目录项有残留能够尝试去补齐节点和目录项；但如果局部文件的节点和目录项同时失落则无奈补齐。因为程序代码文件不具备规律性，若其数据区失落也无奈补齐。图为复原出的局部目录构造： 服务器数据恢复后果：在尽可能的尝试对虚构磁盘文件及其中的数据库文件进行修补之后，由管理员对复原进去的数据进行验证，重要数据准确无误，只有极少局部数据失落，数据恢复胜利。

服务器数据恢复环境：某品牌MSA SAN Storage存储；共8块SAS硬盘：7块硬盘组成RAID5，1块热备盘；基于RAID5的LUN有6个，均调配给HP-Unix小机应用，下层做的LVM逻辑卷，重要数据为Oracle数据库及OA服务端。 服务器故障：RAID5有2块硬盘损坏，只有一块热备盘激活，RAID5瘫痪，下层LUN无奈应用。服务器管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、北亚服务器数据恢复工程师收到硬盘当前检测所有硬盘没有发现物理故障，应用硬盘坏道检测工具检测也没有发现坏道。 2、备份数据。应用工具将所有硬盘都镜像成文件。 3、故障剖析：因为硬盘没有发现坏道和其余物理故障，服务器数据恢复工程师初步判断RAID故障的起因是某些磁盘读写不稳固。因为该型号存储控制器的磁盘检测策略严格，会把性能不稳固磁盘认定为坏盘并踢出RAID组。一旦掉线的盘超过该RAID容许掉盘的极限，该RAID将不可用，下层基于RAID的LUN也会不可用。 4、剖析RAID构造：该存储的LUN都是基于RAID的，因而须要先剖析底层RAID信息，而后依据剖析获取到的信息重构原始RAID。服务器数据恢复工程师通过剖析发现4号盘的数据同其余盘不太一样，初步判断该盘是hot Spare盘。接着剖析其余盘，剖析Oracle数据库页在每个磁盘中散布的状况，并依据数据分布的状况剖析出RAID条带大小、磁盘程序、数据走向等RAID信息。 5、剖析RAID掉线盘：依据剖析获取到的RAID信息应用北亚自主开发的RAID虚构程序将原始的RAID虚构重构。但因为该RAID一共掉线两块盘，因而须要剖析这两块硬盘掉线的程序。服务器数据恢复工程师剖析每一块硬盘中的数据后发现有一块硬盘在同一个条带上的数据和其余硬盘显著不一样，初步判断此盘是最先掉线的。通过北亚自主开发的RAID校验程序对这个条带做校验，最终确定最先掉线的硬盘了。 6、剖析RAID中的LUN信息：因为LUN是基于RAID的，将RAID虚构重构进去当前剖析LUN在RAID中的分配情况和LUN调配的数据块MAP。只须要将每一个LUN的数据块散布MAP提取进去，而后针对这些信息编写相应的程序对所有LUN的数据MAP做解析，而后依据数据MAP导出所有LUN的数据即可。 7、解析LVM逻辑卷：对导出来的LUN数据做剖析发现所有LUN中均蕴含HP-Unix的LVM逻辑卷信息。通过解析每个LUN中的LVM信息发现一共有三个LVM，一个LVM中划分了一个LV，寄存OA服务器端的数据；另外一个LVM中划分了一个LV，寄存长期备份数据；残余4个LUN组成一个LVM，划分了一个LV，寄存Oracle数据库文件。北亚服务器数据恢复工程师编写LVM解释程序将每个LVM中的LV卷解释进去，但解释程序出错。 8、修复LVM逻辑卷：分析程序报错的起因，开发工程师debug程序出错的地位。文件系统工程师对复原进去的LUN做检测，检测存储瘫痪是否会导致LMV逻辑卷的信息损坏。通过检测发现存储瘫痪的确导致LVM信息损坏。人工对损坏的区域进行修复，并同步批改程序，从新解析LVM逻辑卷。 9、解析VXFS文件系统：搭建HP-Unix环境，将解释进去的LV卷映射到HP-Unix，并尝试Mount文件系统。后果Mount文件系统出错，尝试应用“fsck –F vxfs” 命令修复vxfs文件系统，但修复后还是不能挂载。剖析可能是底层vxfs文件系统的局部元数据可能被毁坏，须要进行手工修复。 10、修复VXFS文件系统：服务器数据恢复工程师对解析进去的LV进行剖析，依据VXFS文件系统的底层构造校验此文件系统是否残缺。通过剖析发现底层VXFS文件系统有问题，存储瘫痪的同时文件系统正在执行IO操作，局部文件系统元文件损坏。手工修复这些损坏的元文件保障VXFS文件系统可能失常解析。将修复好的LV卷挂载到HP-Unix小机上尝试Mount文件系统，文件系统没有报错，胜利挂载。 11、复原所有用户文件：在HP-Unix机器上mount文件系统后将所有数据均备份至指定磁盘空间。 12、检测数据库文件是否残缺：应用Oracle数据库文件检测工具检测每个数据库文件是否残缺，没有发现错误。应用北亚自主研发的Oracle数据库检测工具检测，发现有局部数据库文件和日志文件校验不统一，安顿数据库工程师对此类文件进行修复并再次校验，直到所有文件通过校验。 13、启动Oracle数据库：将复原进去的Oracle数据库附加到原始生产环境的HP-Unix服务器中尝试启动Oracle数据库，Oracle数据库启动胜利。 数据验证：启动Oracle数据库和OA服务端，在本地电脑装置OA客户端，通过OA客户端对最新的数据记录以及历史数据记录进行验证，并且安顿不同部门人员进行近程验证。通过验证确认数据残缺无误，数据恢复胜利。

服务器数据恢复环境：华为OceanStor某型号存储，反对SAN和NAS存储协定。 服务器故障：存储上一个NAS卷中的数据失落，卷大小为2T，管理员发现后，关闭系统利用，进行上传数据。通过查看发现失落数据的类型为office文档、PDF文件、图片文件（JPG、JPEG、PNG等）、视频文件（MP4、AVI等）、音频文件（MP3等）。服务器管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、服务器数据恢复工程师筹备好备份服务器，将备份服务器连贯到故障存储环境中。2、通过存储管理界面找到失落数据的卷所对应的存储LUN，该卷对应两个存储LUN。3、将对应的存储LUN映射到备份服务器，应用软件对LUN进行镜像备份。4、剖析存储LUN的构造，解析两个LUN之间的对应关系。 LUN1： LUN2： 5、剖析2T的NAS卷在两个存储LUN中的散布状况，将2T卷虚构重组进去。6、剖析2T卷的存储构造，获取文件系统类型、超级块、节点等构造。7、剖析该2T卷中的超级块、节点等构造，获取节点、目录项、数据区之间的索引关系。 超级块： 节点： 8、北亚数据恢复工程师编写程序解析目录项、节点，提取数据。 9、对2T卷的所有空间进行扫描，发现文件系统的目录项还在，然而节点曾经全副失落，查看文件系统的日志也没有找到无效的节点。图为找到的局部目录项及其对应节点： 目录项： 节点： 10、尝试按类型间接复原数据文件，而后依据目录在卷中的偏移地位，数据文件在卷中的偏移地位和管理员提供的对应文件类型、文件大小去匹配目录项和数据文件。尽管这种形式存在不确定性，然而通过服务器数据恢复工程师的致力下，胜利匹配用户所须要的数据，服务器数据恢复胜利。

服务器数据恢复环境：EMC服务器，采纳NAS（Isilon S系列存储）；共三个节点，每一节点配置12块SATA接口、单盘容量为3T的硬盘。 服务器故障：管理员误删除虚拟机，被误删除的虚拟机中存储的是数据库、MP4、AS、TS类型的视频文件等。被误删除的虚拟机是通过NFS协定共享到ESX主机，视频文件通过CIFS协定共享给虚拟机（WEB服务器），NFS共享的所有数据（虚拟机）被删除而CIFS共享的数据则没有被删除。管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、将所有硬盘进行备份。2、服务器数据备份实现后在Isilon的web治理界面中将Isilon失常关机。将备份好的服务器数据放到北亚数据恢复平台中对数据进行剖析。 3、本案例服务器数据失落的起因是误删除，所以不必过多思考冗余级别，须要重点剖析的是数据删除后Indoe及数据MAP是否发生变化。4、因为服务器中被删除的虚构磁盘文件大小都在64G或以上，除此之外没有其余大文件。北亚数据恢复工程师编写扫描所有文件Indoe的程序，将文件不小于64G的indoe全副扫描进去。通过对Indoe进行扫描找出数据MAP地位，发现其index指向的内容已不再是失常数据，并且所有节点上的Indoe均是同样的状况。5、再次剖析Inode，发现大文件的数据MAP会有多层（树结构）,并且数据MAP中会记录文件的惟一ID，数据恢复工程师尝试找到文件最底层的数据MAP。数据恢复工程师对文件最底层的数据MAP做遍历跟踪操作，发现最低层的数据MAP还存在。6、通过文件的Inode对文件的惟一ID进行提取工作，而后对所有合乎该ID的数据MAP做聚合。并依据数据MAP中的VCN号做排序，数据恢复工程师通过剖析发现每个文件的前17088项数据MAP都不存在，实践上每个文件的前17088项数据是无奈复原。7、通过数据换算确定失落的数据MAP项的大小一共不到1G，删除的文件全是虚拟机的vmdk文件，外面都是NTFS的文件系统，NTFS文件系统的MFT根本都在3G的地位。只须要在每个vmdk文件的头部手动伪造一个MBR和DBR就能够解释vmdk外面的数据了。8、对扫描到的数据MAP做解释，并依据VCN号的程序导出数据，没有MAP的状况保留为零。9、数据恢复工程师将vmdk文件导出，发现文件比理论状况要小、vmdk中MFT的地位也与本身形容不符。手动随机验证了几个MPA发现都能指向数据区，而程序解释MAP的形式也都没有问题。呈现这种状况的起因可能为文件稠密！10、北亚数据恢复工程师从新调整了代码再次导出vmdk，这次导出的数据失常且MFT的地位也在相应地位。手工伪造一个MBR，分区表以及DBR，再用北亚开发的文件系统解释工具解释文件系统胜利，导出vmdk外面的数据库及视频文件。11、验证vmdk中的数据库及视频文件没有发现问题，批量导出所有重要的vmdk文件，再手动的去批改每个vmdk文件。 服务器数据恢复后果：将所有重要的数据恢复实现后，由服务器管理员对复原进去的所有数据做完整性及准确性检测，最终确定数据齐全没有问题，数据恢复胜利。

服务器数据恢复环境：某品牌StorageWorks服务器；8块SAS硬盘组成raid5，一块热备盘。 服务器故障：服务器运行过程中有两块硬盘先后离线，服务器瘫痪，lun无奈失常应用。服务器管理员分割咱们数据恢复核心进行数据恢复。咱们数据恢复核心的服务器数据恢复工程师对服务器中所有磁盘进行物理检测和坏道检测，没有发现问题。 服务器数据恢复流程：1、对故障服务器所有硬盘做镜像，以防在数据恢复过程中对原始数据造成二次毁坏。备份的局部数据如下图： 2、服务器故障起因剖析：目前初步理解的状况为基于RAID组的LUN有6个，均调配给HP-Unix小机应用，下层做的LVM逻辑卷，重要数据为Oracle数据库及OA服务端。一旦故障服务器中的某些磁盘性能不稳固，该型号服务器中的控制器会将其认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘达到RAID级别容许掉盘的极限，那么这个RAID将不可用，服务器瘫痪。 3、剖析服务器RAID组构造：服务器的LUN都是基于RAID组的，要想复原服务器数据就须要先剖析底层RAID组的信息，而后依据剖析的信息重构原始的RAID组。服务器数据恢复工程师剖析所有硬盘后发现4号盘的数据同其余盘不太一样，初步认为是hot Spare盘。接着剖析其余数据盘，剖析Oracle数据库页在每个磁盘中散布的状况，并依据数据分布的状况获取到RAID组的条带大小，磁盘程序及数据走向等RAID组的重要信息。 4、剖析服务器RAID组掉线盘：根据上述剖析的RAID信息，通过北亚自主开发的RAID虚构重组程序将原始的RAID组虚构进去。但因为整个RAID组中一共掉线两块盘，因而须要剖析这两块硬盘掉线的程序。仔细分析每一块硬盘数据，发现有一块硬盘在同一个条带上的数据和其余硬盘显著不一样，因而初步判断此硬盘可能是最先掉线的，通过北亚自主开发的RAID校验程序对这个条带做校验，最终确定最先掉线的硬盘。 5、剖析RAID组中的LUN信息：因为LUN是基于RAID组的，因而须要根据上述剖析的信息将RAID组最新的状态虚构进去，而后剖析LUN在RAID组中的分配情况,以及LUN调配的数据块MAP。因为底层有6个LUN，因而只须要将每一个LUN的数据块散布MAP提取进去，而后针对这些信息编写相应的程序，对所有LUN的数据MAP做解析，而后依据数据MAP导出所有LUN的数据。导出的数据如下图： 6、服务器LVM逻辑卷及VXFS文件系统修复：服务器数据恢复工程师剖析所有生成进去的LUN，发现所有LUN中均蕴含HP-Unix的LVM逻辑卷信息。数据恢复工程师尝试解析每个LUN中的LVM信息，发现一共有三套LVM：45G的LVM中划分了一个LV，寄存OA服务器端的数据；190G的LVM中划分了一个LV，寄存长期备份数据；残余4个LUN组成一个2.1T左右的LVM，划分了一个LV，寄存Oracle数据库文件。服务器数据恢复工程师编写解释LVM的程序，尝试将每套LVM中的LV卷都解释进去，但发现解释程序出错。仔细分析程序报错的起因，开发工程师debug程序出错的地位，文件系统工程师对复原的LUN做检测，检测LVM信息是否会因存储瘫痪导致LMV逻辑卷的信息损坏。通过检测发现的确因为存储瘫痪导致LVM信息损坏。尝试人工对损坏的区域进行修复，并同步批改程序，从新解析LVM逻辑卷。搭建HP-Unix环境，将解释进去的LV卷映射到HP-Unix，并尝试Mount文件系统，后果Mount文件系统出错。尝试应用“fsck –F vxfs”命令修复vxfs文件系统，修复后还是不能挂载。狐疑底层vxfs文件系统的局部元数据可能毁坏，须要进行手工修复。仔细分析解析进去的LV，并依据VXFS文件系统的底层构造校验此文件系统是否残缺。剖析发现底层VXFS文件系统果然有问题，原来存储瘫痪的同时此文件系统正在执行IO操作，因而导致局部文件系统元文件没有更新和损坏。数据恢复工程师对这些损坏的元文件进行手工修复，保障VXFS文件系统可能失常解析。再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，文件系统没有报错，胜利挂载。 7、检测Oracle数据库文件并启动数据库：在HP-Unix机器上mount文件系统后，将所有用户数据均备份至指定磁盘空间。所有用户数据大小在1.2TB左右。局部文件目录截图如下： 应用Oracle数据库文件检测工具检测每个数据库文件是否残缺，没有发现错误。应用北亚自主研发的Oracle数据库检测工具检测，发现局部数据库文件和日志文件校验不统一，数据库数据恢复工程师对此类文件进行修复并校验，直到所有文件校验均齐全通过。将复原进去的Oracle数据库附加到原始生产环境的HP-Unix服务器中，尝试启动Oracle数据库，Oracle数据库启动胜利。 8、启动Oracle数据库，启动OA服务端，在本地电脑上装置OA客户端。通过OA客户端对最新的数据记录以及历史数据记录进行验证，并且有安顿不同部门人员进行近程验证。最终数据验证无误，数据残缺，数据恢复胜利。

服务器故障：戴尔某型号服务器因为raid损坏而解体，因为服务器数据涉密，管理员分割咱们数据恢复核心上门进行数据恢复。 服务器故障检测：数据恢复工程师携带相干设施到现场对服务器进行检测，发现导致服务器解体的起因是raid阵列中某些硬盘掉线。硬件工程师对所有磁盘进行物理检测后没有发现物理故障和坏道。随后数据恢复工程师借助数据恢复软件将故障服务器中的所有磁盘镜像到筹备好的数据恢复服务平台上。 服务器数据恢复过程：1、剖析故障服务器RAID构造。该故障服务器的LUN全副基于RAID阵列组，所以要复原服务器数据首先要剖析服务器底层RAID信息，而后依据剖析获取到的信息重构原始的RAID组。服务器数据恢复工程师对raid阵列进行剖析后发现服务器中有两块硬盘离线。因为6号盘和10号盘都属于Hot Spare，但在服务器产生故障时6号Hot Spare替换了掉线的5号硬盘，可10号盘因为未知起因未启用。服务器尽管胜利激活了6号盘Hot Spare，但RAID中仍缺失一块硬盘，数据没有胜利同步到6号硬盘。服务器数据恢复工程师持续剖析其余硬盘，获取数据在硬盘中的散布法则，RAID条带的大小，每块磁盘的程序等信息。2、重组raid剖析掉线盘程序。依据获取到的raid信息，数据恢复工程师应用北亚自主开发的RAID虚构程序虚构重组故障服务器raid。重组实现后剖析服务器中两块掉线硬盘的掉线程序。通过排查，服务器数据恢复工程师发现有一块硬盘在同一个条带上的数据和其余硬盘显著不统一，初步判断此硬盘可能是最先掉线的。通过北亚自主开发的RAID校验程序对这个条带做校验，最终确定最先掉线的硬盘。3、剖析RAID组中的LUN信息。基于获取到的raid信息，掉盘程序，依据剖析后果重组raid。剖析LUN在RAID组中的调配信息和LUN调配的数据块MAP。而后依据这些信息应用北亚自主开发的raid数据恢复程序，解释LUN的数据MAP并导出LUN的所有数据。4、解释ZFS文件系统并修复。应用北亚自主开发的ZFS文件系统解释程序对生成的LUN做文件系统解释，解析所有文件节点及目录构造。 服务器数据恢复后果：由服务器管理员亲自对数据进行验证，所有数据失常、残缺，本次数据恢复胜利。

服务器数据恢复环境：ibm x3850系列服务器；5块硬盘组成raid5磁盘阵列；linux redhat 5.x操作系统；oracle数据库。 服务器故障：服务器上两块硬盘因为未知故障离线，服务器数据失落，管理员分割咱们数据恢复核心要求复原故障服务器的数据。通过服务器数据恢复工程师对故障服务器进行初检，发现服务器阵列中有两块硬盘处于离线状态，热备盘未激活。硬盘无物理故障，无显著同步体现。 服务器数据恢复过程：1、将故障服务器关机，标记好故障盘后取出槽位挂载至筹备好的数据恢复服务器环境进行镜像备份。对原硬盘镜像后发现除了2号盘有10-20个坏扇区外其余硬盘均失常。实现镜像后将硬盘重新安装到原服务器。2、服务器数据恢复工程师剖析备份盘中的raid构造，获取阵列中的raid条带大小、校验方向、条带规定以及meta区域等信息。通过剖析发现最佳盘序构造是0-1-2-3，缺失3号盘，构造如下图： 依据剖析进去的raid信息虚构搭建一组raid5环境，组好后进行数据验证，200M以上的最新压缩包解压无报错，依照这一构造将虚构raid生成到一块硬盘上，通过USB的形式把复原后的单盘接入原服务器，通过软件启动故障服务器后进行全盘回写。 3、数据回写实现后无奈进入操作系统，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。数据恢复工程师重启服务器后发现文件的权限、工夫、大小都有显著谬误，对根分区再次剖析定位出错的/sbin/pidof/，发现问题的起因是2号盘坏道。4、利用其余盘对2号盘的损坏区域进行xor补齐并从新校验文件零碎，仍然报错，数据恢复工程师再次对inode表进行查看，发现2号盘损坏区域有局部节点体现为(图中的55 55 55局部)： 5、尽管节点中形容的uid还失常存在，但大小、属性、最后的调配块全副是谬误的。通过日志确定原节点块的节点信息后进行修改，从新dd根分区，执行fsck -fn /dev/sda5检测，报错状况如下图： 6、通过剖析发现，原来3号盘最先离线，节点信息新旧交加导致有多个节点共用数据块。数据恢复工程师按节点所属的文件进行区别，革除谬误节点后再次执行fsck -fn /dev/sda5，仍然有局部位于doc目录下的节点报错。因为不影响启动所以强行修复后重启零碎，零碎失常，启动数据库失常。 7、由服务器管理员亲自对服务器数据进行验证，验证后果示意数据失常，数据恢复胜利。

服务器数据恢复环境：VMware ESX服务器；服务器文件系统：VMFS；8块硬盘组建RAID5，4号盘是热备盘。 服务器故障：服务器两块硬盘指示灯亮黄色，机房管理员检测后初步判断这2块盘呈现物理故障，序列号无奈读取，在SAS扩展卡上无奈辨认。管理员分割咱们数据恢复核心对raid进行数据恢复。 服务器数据恢复过程： 1、硬盘物理故障修复。硬件工程师拿到所有服务器硬盘后首先查看了raid中的两块掉线盘，将故障盘连贯到内部SAS扩展卡上加电检测，磁头不寻道。硬件工程师在无尘工作间对故障硬盘进行收盘修复。修复实现后对故障盘数据做镜像。 2、重组RAID5。服务器数据恢复工程师发现所有硬盘的的0扇区都有“55 AA”标记，0x01C2H处示意该分区的类型，这里显示“05”，代表这是一个扩大分区。因而从0扇区看这是一个不失常的MBR分区构造。依照这一办法持续查找，别离在7号盘和8号盘找到了“55 AA”的标记。8号盘查问后果如下。这是一个失常的MBR分区，其0x01C6处数值代表指向的下一个扇区为GPT的头部。 7号盘查问后果如下。其0x01C6处数值代表指向下一个扇区。然而下一个扇区很显著不是GPT的头部。 由此能够确定8号盘是第一块盘，7号盘可能是最初一块盘。GPT分区所在扇区起始于172032扇区，因而初步确定LUN的起始扇区是172032扇区。 条带也就是raid阵列块，是RAID解决数据的根本单元，不同的RAID的条带大小也各不相同。RAID5的1个条带组中有1个校验区，能够依据这个法则对该raid5进行剖析，也能够通过比较法确定条带大小。如某一条带组中的校验区跟这一条带组中的非校验区可能相差很显著，通过WinHex查看做比照就能够找到条带大小。服务器数据恢复工程师对该服务器raid进行剖析确定条带大小为1024个扇区。依照1024扇区宰割，使一个记录为一个条带的大小，如图5所示。并且7块盘跳到同一记录283123。 当7块盘都定位到同一地位时，通过比照就能够判断校验区的走向，继而判断整个RAID5的走向。之前曾经判断出8号盘是第一块盘了，把8号盘放在第一个地位，确定RAID5为左走向，盘序为8，2，3，4，1，7，5。 服务器数据恢复工程师初步确定了LUN的起始扇区是172032扇区。应用数据恢复工具跳到172032扇区对硬盘的应用状况进行察看，失常状况下这个扇区所属条带中的5号盘应该是校验区，但理论状况中却显示校验区为8号盘。依据该raid走向的法则，5号盘的校验区应该在172032-1024=171008扇区，即上一个条带。跳转到171008扇区，发现校验区为5号盘。因而能够确定LUN的起始扇区为171008扇区。 北亚数据恢复工程师应用数据恢复工具依照确定的盘序重组raid增加进去，如图所示。抉择RAID5，Stripe size 512KB，左异步。 点击Build进行重组。组好后，因为数据从10248=8192个扇区开始，若业余复原工具没有跳转到此扇区的性能，那么刚组好的RAID必须和一个文件再进行一次Build重组操作。RAID的起始扇区(Start sectors)抉择8192，这个文件能够任意抉择起始扇区和大小(Count sectors)，下图为重组后的raid5磁盘阵列。* 服务器数据恢复后果：RAID5磁盘阵列重建实现后由服务器管理员验证通过，本次数据恢复工作实现。

虚拟机数据恢复环境：Dell PS系列服务器（用于VMware虚拟主机）；VMware ESXi5.5版本；虚拟机操作系统：Windows Server 2008；数据库：SQL Server 2008数据库服务器（治理宏桥和索菲两套利用数据库）；虚拟机磁盘：200G数据盘（精简模式）+ 160G快照数据盘。 虚拟机故障：意外断电导致某台虚拟机不能失常启动，配置文件中除了磁盘文件以外其余配置文件全副失落。此时xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。找VMware工程师诊断后，尝试新建一个虚拟机来解决故障，但发现ESXi存储空间有余。因而就将故障虚拟机下的xxx-flat.vmdk磁盘文件删除了，这时ESXi存储就有200多G的残余空间了，VMware工程师从新创立了一个40G的虚拟机，并调配了固定大小的虚构磁盘。 虚拟机数据恢复过程：1、备份数据。在VMware vSphere Client上将挂载的RD220i存储中VMFS卷以失常形式卸载掉，而后将RD220i存储上的VMFS卷通过网线的形式连贯到备份服务器上，应用工具将整个VMFS卷以扇区的形式镜像到已筹备好的备份空间上，之后的剖析和数据恢复操作均在备份的数据上进行。 2、剖析故障起因。仔细分析VMFS卷的底层数据，发现ESXi主机的忽然断电导致故障虚拟机目录下的目录项呈现毁坏，然而这种毁坏不会影响虚拟机的重要数据，只是毁坏了文件的目录项而已，能够通过人工进行修复。而人为删除某个文件的话，则目录项对应的数据区索引会被清掉，也不会影响删除文件的理论数据。这种状况可依据删除虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在VMFS卷自由空间中进行碎片匹配和合并，最终复原删除的虚构磁盘文件。然而在上述的两种状况之下又新建了一台虚拟机，并且调配了虚构磁盘。通过仔细分析发现调配的40G虚构磁盘曾经全副清零了（在创立虚构磁盘的时候会抉择创立磁盘的类型），也就是说这个新建的虚拟机所占用的磁盘空间全副被清零。 如果新虚构磁盘占用了删除虚拟机磁盘所开释的空间，那么此局部空间将无奈复原的。图一：（故障虚拟机的目录项区域） 3、虚拟机数据恢复实施方案一：a、底层剖析。依据VMFS卷的构造以及删除虚构磁盘的文件系统信息，在底层的自由空间中扫描合乎删除虚拟机磁盘的区域，并统计其数量和大小是否合乎删除虚构磁盘的大小。b、依据虚构磁盘中的文件系统的信息将扫描到的碎片进行排列组合，后果发现两头有好多碎片缺失，再对这些缺失的碎片进行从新扫描，发现这些碎片的确没有找到。c、将扫描到的碎片依照虚构磁盘本来的程序重组，对于没有找到的碎片暂且留空。d、利用虚构磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚构磁盘。e、用业余工具解释虚构磁盘中的文件系统，因缺失好多数据，文件系统解释过程中有很多报错，提醒某些文件损坏。 图二（解释完的文件系统）： f、在解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录构造失常。然而在尝试将备份导入数据库中时，数据库导入程序提醒报错。 图三（宏桥备份和索菲备份的局部目录构造）： 导入.BAK文件报错信息如下： 4、虚拟机数据恢复实施方案二：a、因为计划一中没有将原始的数据库文件复原进去，并且其中好多备份文件都无奈失常应用。因而采纳第二套计划来复原尚未复原的数据库文件。b、依据SQL Server数据库的构造去自由空间中找到数据库的开始地位。在数据库的构造中，数据库的第9个页会记录本数据库的数据库名。因而依据这个特色能够核查此数据库的头部页是否是正在查找的。并且数据库的每个页中都会记录数据库页编号以及文件号，所以依据这些特色编写数据库扫描程序，而后利用程序去底层扫描所有合乎数据库页的数据碎片。c、将扫描进去的碎片按程序重组成一个残缺MDF文件，再通过MDF校验程序检测整个MDF文件是否残缺。在整个校验过程中，只有cl_system3.dbf和erp42_jck.dbf因有局部碎片没有找到外，其余数据库均校验胜利。校验完的MDF文件如下： d、cl_system3.dbf和erp42_jck.dbf因底层有很多碎片没有找到（初步狐疑可能被笼罩），因而校验不通过。如下是cl_system3.dbf文件中某个碎片失落的区域： 5、虚拟机数据恢复实施方案三：a、因为上述两个计划并没有将所有的数据库文件全副复原进去，还有cl_system3.dbf和erp42_jck.dbf这2个文件因缺失局部页无奈失常应用。因而须要采纳备份来复原这两个数据库文件，然而在查看完这两个文件的备份后发现cl_system3.dbf的3月某一天的数据因备份机制故障没有备份进去，而erp42_jck.dbf的3月份备份则全副没有，只有4月份的全副增量备份： 因为erp42_jck.dbf文件中只缺失大量的页，因而能够依据缺失的页号在增量备份中查找，再将找到的页补到erp42_jck.dbf文件中，这样能够复原一部分失落的数据库页。补完后还是缺失局部页，无奈失常应用。然而通过北亚自主开发的数据库解析程序将erp42_jck.dbf文件中比拟重要的几十张表胜利导出，并胜利导入到新建的数据库中。 验证数据：在本地服务器中搭建和原始环境一样的数据库环境（SQL Server 2008），由管理员通过Teamviewer近程工具连贯到验证服务器，并装置下层宏桥应用软件。验证数据库根本没有发现问题，下层利用能够失常运行，数据记录也都根本没有缺失，数据库胜利挂载。本次数据恢复实现。

服务器存储数据恢复环境： EVA存储构造：1台EVA某型号控制器+3台EVA某型号扩大柜+28块FC硬盘。 服务器存储故障： EVA存储构造中的两块磁盘掉线导致存储中的某些LUN失落不可用，管理员分割咱们数据恢复核心进行数据恢复。 服务器存储数据恢复过程： 1、北亚数据恢复核心收到故障存储的磁盘后，由硬件工程师对所有磁盘做物理检测，没有发现物理故障。而后应用坏道检测工具检测磁盘坏道，没有发现坏道。磁盘坏道检测日志如下： 2、备份数据。 数据恢复工程师应用工具将所有磁盘都镜像成文件。备份完局部数据如下： 3、剖析故障起因。 通过后面的检测，磁盘没有发现物理故障或者坏道，数据恢复工程师判断故障产生起因是某些磁盘读写不稳固。因为EVA控制器磁盘检测的策略十分严格，一旦有磁盘呈现性能不稳固的迹象，就很有可能被EVA控制器断定为坏盘并被踢出磁盘组。如果某个LUN的同一个条带中掉线的盘达到肯定的数量，这个LUN将不可用。如果EVA中所有的LUN都有盘掉线，那么所有LUN都会受影响，所以2块盘掉线导致整个存储的LUN都不可用的状况也有可能产生。本案例的理论状况是现存8个LUN，损坏7个LUN，失落6个LUN，须要复原所有LUN的数据。 4、剖析LUN的构造。 HP-EVA的LUN都是以RAID条目标模式存储数据的，EVA将每个磁盘的不同块组成一个RAID条目。RAID条目标类型有多种。咱们须要剖析出组成LUN的RAID条目类型和每个RAID条目是由哪些盘的哪些块组成。这些信息都寄存在LUN_MAP中，每个LUN都有一份LUN_MAP，EVA将LUN_MAP别离寄存在不同的磁盘中，并应用索引指定其地位。因而，只有在每个磁盘中找出指向LUN_MAP的索引就能够找到现存LUN的信息了。 5、剖析失落的LUN。 尽管磁盘中记录了指向LUN_MAP的索引，然而它只记录现存的LUN，失落的LUN是不会记录索引的。因为EVA中删除一个LUN只会革除这个LUN的索引，而不会革除这个LUN的LUN_MAP。只有扫描所有磁盘找到所有合乎LUN_MAP的数据块，而后排除掉现有的LUN_MAP，剩下的LUN_MAP也不肯定全是删除的，也有一些是以前旧的，但此时无奈在LUN_MAP中筛选，只能通过程序将所有LUN_MAP的数据都复原进去，人工的去核查哪些LUN是删除的。 6、剖析掉线磁盘。 尽管通过检测没有发现磁盘有物理故障和坏道，但还是可能因为性能不稳固从EVA磁盘组中脱离。因为这些脱离的磁盘寄存旧的数据，所以在生成数据的时候须要将这些磁盘都排除掉。那么如何判断那些掉线的磁盘呢？因为LUN的RAID构造大多都是RAID5，只须要将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值做比拟就能够判断这个条目中是否有掉线盘。将一个LUN的所有LUN_MAP都校验一遍就能够晓得这个LUN中哪些RAID条目中有掉线盘。这些RAID条目中都存在的那个盘就肯定是掉线盘。排除掉线盘，而后依据LUN_MAP复原所有LUN的数据即可。 7、编写数据恢复程序。 上述的故障剖析以及解决思路最终都须要编写程序来实现。北亚数据恢复工程师编写扫描LUN_MAP的程序扫描全副LUN_MAP，联合人工剖析获取最准确的LUN_MAP；编写检测RAID条目标程序检测所有LUN中掉线的磁盘，联合人工剖析排除掉线的磁盘；编写LUN数据恢复程序，联合LUN_MAP复原所有LUN数据。 8、复原所有LUN数。 依据编写的程序去实现不同的性能，而后人工核查每个LUN，确认是否和管理员形容的统一。局部复原进去的LUN的数据： 数据验证： 依据管理员形容，所有LUN的数据能够分成两大部分：一部分是Vmware的虚拟机，一部分是HP-UX上的裸设施，裸设施里寄存的是Oracle的dbf数据库。因为咱们复原的是LUN，无奈看到外面的文件，因而须要将这些LUN用人工核查的形式确定哪些LUN寄存Vmware的数据，哪些LUN寄存HP-UX的裸设施。而后将LUN挂载到不同的验证环境中验证复原的数据是否残缺。别离部署好Vmware虚拟机的验证环境和Oracle数据库的验证环境并进行验证，修复好Oracle数据库（过程就不赘述了）并移交数据。

数据库数据恢复环境：Dell PowerEdge R系列服务器；7块SAS硬盘别离组成raid1（2块硬盘）和raid5（5块硬盘）；sql server数据库寄存在C盘中。 数据库故障：管理员在日常巡检过程中发现服务器C盘空间行将填满，于是将数据库门路指向了D盘，在D盘生成了一个.ndf文件。大概10天后，数据库呈现故障，连贯生效，无奈失常附加查问。管理员分割咱们数据恢复核心进行数据恢复。 数据库复原过程：1、备份数据。数据恢复工程师将所有磁盘都镜像成文件。2、数据库故障剖析。因为数据库文件所在磁盘容量有余，导致数据库无奈持续失常运行，呈现逻辑谬误。3、剖析RAID组构造。原服务器上7块硬盘中的2块组建RAID1装置操作系统，其余的5块硬盘做RAID5存放数据。服务器数据恢复工程师剖析RAID1和RAID5的相干构造，虚构重组出RAID1和RAID5并查看剖析其中数据。4、剖析原始数据库文件。在数据库呈现问题后，管理员屡次尝试复原数据库，并且复原操作都是在原环境下进行的，导致原始数据库文件被更改笼罩，磁盘空间被屡次复写，无奈应用尝试复原操作之后的数据库文件进行修复。数据恢复工程师和管理员沟通得悉：数据库产生故障后，尝试数据恢复之前，管理员对故障数据库文件进行过备份。5、服务器数据恢复工程师将之前备份的数据库文件从虚构出的RAID5空间中拷贝进去，尝试在数据库中附加，附加失败，谬误提醒如下： 谬误提醒主数据库文件和次级数据库文件不匹配，查看.ndf文件底层，发现.ndf文件中简直没有数据，尝试勾销.mdf文件和.ndf文件之间关联，只用.mdf文件进行附加。尝试后发现，只用.mdf文件附加时也产生谬误，然而谬误提醒扭转。 此时谬误提醒日志文件（.ldf）和数据库文件（.mdf）不匹配。6、对数据库尝试进行无数据库附加，附加胜利。然而发现数据库系统表损坏，无奈失常应用。 7、对数据库的零碎表尝试修复，但因为零碎表损坏过于重大，无奈修复。 8、数据库记录提取，解析数据库文件中的数据库记录。北亚数据恢复工程师编写相应的程序提取数据库文件中的数据库记录。 9、依据以前的数据库备份获取数据库中的表构造，重构表构造并将提取出的数据库记录导入到新的表中。 10、数据验证。由管理员亲自对提取出的数据库记录进行验证，没有发现问题，确认数据完全恢复。 数据库数据安全小贴士：要正当调配数据库文件所在磁盘的空间，及时清理垃圾数据，保障数据库的失常、平安运行。

服务器故障：某公司的一台某品牌x3850服务器raid5中两块磁盘先后掉线，服务器解体。故障服务器的操作系统为linux redhat，利用为公司oa，数据库采纳oracle。因oracle曾经不再对此oa提供后续反对，管理员分割咱们数据恢复核心要求尽可能复原数据和零碎。数据恢复工程师对故障服务器进行检测，发现热备盘没有启用，硬盘无显著物理故障，无显著同步体现。 服务器数据恢复计划：1、爱护原环境，敞开服务器，确保在复原过程中不再开启服务器。2、将故障硬盘标好序号，确保在拿出槽位后能够齐全还原。3、将故障硬盘挂载至只读环境，对所有故障硬盘做齐全镜像(参考<如何对磁盘做残缺的全盘镜像备份>)。备份实现后交回原故障盘，之后的复原操作直到数据确认无误前不再波及原故障盘。4、对备份盘进行RAID构造剖析，失去其原来的RAID级别，条带规定，条带大小，校验方向，META区域等。5、依据失去的RAID信息搭建一组虚构的RAID5环境。6、进行虚构磁盘及文件系统解释。7、检测虚构构造是否正确，如不正确，反复4-7过程。8、确定数据无误后，按用户要求回迁数据。如果依然应用原盘，需确定曾经齐全对原盘做过备份后，重建RAID，再做回迁。回迁操作系统时，能够应用linux livecd或win pe(通常不反对)等进行，也能够在故障服务器上用另外硬盘装置一个回迁用的操作系统，再进行扇区级别的回迁。9、数据移交后，由北亚数据恢复核心缩短保存数据3天，以防止可能疏忽的纰漏。 服务器数据恢复过程：1、对故障服务器中的所有硬盘进行残缺镜像，镜像后数据恢复工程师发现2号盘有10-20个坏扇区，其余磁盘没有发现坏道。2、剖析构造：获取到的最佳构造为0,1,2,3盘序，缺3号盘，块大小为512扇区，backward parity(Adaptec)，构造如下图： 3、组好后进行数据验证，200M以上的最新压缩包解压无报错，确定构造正确。4、间接按此构造生成虚构RAID到一块单硬盘上，关上文件系统无显著报错。5、确定备份包平安的状况下，经管理员批准后，北亚数据恢复工程师对原盘重建RAID，重建时曾经用全新硬盘更换损坏的2号盘。将复原好的单盘用USB形式接入故障服务器，再用linux SystemRescueCd启动故障服务器，之后通过命令进行全盘回写。6、回写后，启动操作系统。失常状况下，这时候所有工作应该实现了，不巧的是，问题还没有解决。 上面是后续的数据恢复过程：1、接前文：回写完所有数据后，启动操作系统报错，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。2、依据错误信息得悉此文件权限有问题，用SystemRescueCd重启后查看，发现此文件工夫，权限，大小均有显著谬误，显然节点损坏。3、从新剖析重组数据中的根分区，定位出错的/sbin/pidof，发现问题产生起因是2号盘的坏道。4、应用0，1，3这3块盘，针对2号盘的损坏区域进行xor补齐。补齐后从新校验文件零碎，仍然有谬误，再次查看inode表，发现2号盘损坏区域有局部节点体现为下图中的55 55 55局部： 5、尽管节点中形容的uid还失常存在，但属性，大小，最后的调配块全副是谬误的。依照所有可能进行剖析，数据恢复工程师确定无奈找回此损坏节点，只能心愿修复此节点，或复制一个雷同的文件过去。6、对所有可能有错的文件通过日志确定原节点块的节点信息，再做修改。7、修改后从新dd根分区，执行fsck -fn /dev/sda5，进行检测，仍然有报错，如下图： 8、依据提醒，在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析，发现因3号盘早掉线，存在节点信息的新旧交加。9、按节点所属的文件进行区别，革除谬误节点后，再次执行fsck -fn /dev/sda5，仍然有极少量的报错信息。依据提醒，发现这些节点多位于doc目录下，不影响系统启动，于是间接fsck -fy /dev/sda5强行修复。10、修复后，重启零碎胜利进入桌面。11、启动数据库服务，启动应用软件，一切正常，无报错。数据恢复及零碎回迁工作实现。

服务器存储故障：同友存储中组建的raid5磁盘阵列因为未知起因解体且无奈启动，raid5中的虚拟机全副失落，其中3台虚拟机中的数据尤为重要，管理员分割咱们数据恢复核心要求对这3台虚拟机进行数据恢复。 服务器存储数据恢复过程：1、剖析存储底层构造。通过与管理员的沟通和对raid的剖析，搞清楚了故障存储的底层构造：多块物理磁盘组成一个存储池并划分多个lun，须要进行数据恢复的为lun1，lun1蕴含了那3台虚拟机。如下图所示： 存储构造 2、重组raid。在对阵列进行剖析重组时，数据恢复工程师发现原存储中的raid5缺失2块硬盘，热备盘曾经启用。（还原故障产生的过程：第一块硬盘掉线后系统启动热备盘进行替换，第二块硬盘掉线时raid5处于降级状态，第三块硬盘掉线导致raid阵列解体。）这种状况下无奈通过校验间接获取失落盘的数据，只能应用和磁盘等同大小的全0镜像进行重组（因为依赖空镜像组成的raid文件系统构造会毁坏重大，相当于每个条带都会缺失两个块的数据，所以除非非凡状况不倡议如此操作）。 重建raid 3、通过重组进去的raid阵列提取LUN。通过对存储构造的进一步剖析获取到存储划分的MAP块，对各个LUN的数据块指针进行解析。北亚数据恢复工程师编写数据提取程序提取LUN碎片。提取实现后进行碎片拼接，组成残缺LUN。 提取LUN 4、导出LUN内所有的虚拟机并尝试启动，因为操作系统被毁坏，虚拟机无奈启动。 5、提取虚拟机内文件。因为虚拟机无奈启动，只能对虚拟机内的文件进行提取，但少数文件毁坏重大，只有多数文件可用，只好持续制订其余数据恢复计划。 6、通过剖析数据库页提取数据。本案例中的虚拟机内有mysql数据库，能够利用数据库底层存储的特殊性进行数据页扫描，提取数据。（因为父盘和快照文件都被损坏，惯例合并操作无奈实现快照合并，应用北亚自主研发的VMFS快照合并程序进行快照合并。）。 7、获取mysql数据页并剖析。依据mysql数据页特色进行数据页扫描并导出（innodb引擎能够应用此计划；myisam因为没有“数据页”这个概念，所以这个计划不可用），剖析零碎表获取各用户表信息，依据各个表的id进行数据页宰割。 8、提取表构造、提取记录。因为数据库应用工夫已久，表构造也曾多次变更，加上零碎表在存储损坏后有局部数据失落，记录提取过程遇到很大阻力。首先获取最后版本数据库各个表的表构造：合并快照前的父盘因为写入较早，应用第一块掉线盘进行校验获取到这个文件的残缺数据，而后提取出其中数据库各个表的表构造，之后管理员提供了最新版的数据库建表脚本。别离应用两组不同的表构造对数据记录进行提取并导入复原环境中的mysql数据库内，而后剔除各个表中因为表构造变更造成的乱码数据，最初将两组数据别离导出为.sql文件。 9、数据验证。因为两个版本的数据库表构造不同，所以管理员分割利用工程师进行调试。调试实现后导入平台，平台调试胜利，本次数据恢复实现。

数据库数据恢复环境：5块2T硬盘组成的RAID5，划分LUN供windows服务器应用；windows服务器内装有Sql Server数据库；存储空间内共有三个逻辑分区大小别离为：500G、800G、2.3T。 数据库故障：未知起因的数据库文件失落，波及到5个数据库约6000张表，不能确定数据存储地位。数据库文件失落后服务器仍处于开机状态，但并未写入大量数据。管理员分割北亚数据恢复核心进行数据恢复。 数据库故障检测：1、数据恢复工程师利用剖析提取进去的RAID信息及外部数据块信息重组RAID。 重组RAID 2、提取LUN内三个分区镜像。3、扫描文件系统内失落文件，未找到被删除的数据库文件，数据库文件失落，无奈通过文件系统层面复原数据。 数据库数据恢复过程：1、通过检测后断定数据库文件失落且无奈复原，数据恢复工程师只能通过扫描数据页，提取页内记录的形式进行数据恢复。2、应用北亚数据恢复核心自主研发的数据页扫描程序扫描分区内数据页并提取。扫描两个分区镜像后发现系统盘分区内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页数量较多，暂定此分区为数据库文件存储空间。 扫描数据页 3、重组零碎表。Sql Server数据库应用零碎表来治理所有用户表，零碎表记录了各表的列数、数据类型及束缚信息等。解析零碎表过程中发现提取出的数据页内零碎表损坏，无奈失常读取信息。数据恢复工程师与管理员沟通后，得悉有备份文件且备份实现后没有大量改变表构造，零碎表可用。4、还原备份。 还原备份 5、别离提取库中各表表构造信息。 提取表构造信息 6、解析表构造脚本。将各表的列信息存入数据库内便于后续应用。 扫描脚本文件 表构造信息存入数据库 7、解析零碎表获取用户表id信息、关联表构造与数据页。（为爱护隐衷，后续步骤波及用户表表名及数据页内数据局部均未截图）8、新建数据库，应用北亚自主编写的软件解析记录并导入到数据恢复环境内。9、整顿复原后果。在此分区内除数据库文件外还存有若干备份文件，导出记录后可能存在反复数据，必须去重。数据恢复工程师编写SQL存储过程进行去重。 数据库去重 10、验证数据。管理员在查验过数据后示意数据没有问题，移交数据到管理员筹备好的存储设备，本次数据恢复胜利。

SQL Server数据库故障状况：某公司一台存储损坏，SQL Server数据库解体。管理员重组存储，复原数据库文件，发现有四个ndf文件大小变为0KB。管理员分割咱们数据恢复核心进行数据恢复。 SQL Server数据库故障剖析：SQL Server数据库大小约80TB，SQL Server数据库中有1223个文件，SQL Server数据库每10天生成一个NDF文件，每个NDF大概500GB，数据库总共蕴含两个LDF文件。存储损坏，NDF文件大小变为0KB，NDF文件在磁盘上可能存在。能够通过编写数据库扫描碎片程序，扫描数据库碎片、拼接碎片复原NDF文件，修复数据库。 SQL Server数据库数据恢复过程：1、磁盘扫描数据库碎片。2、拼接碎片。依据NDF文件的页面特色，依照文件号、页号拼接碎片，重组生成出这些0kb的NDF文件。3、检测数据库文件。应用北亚自主研发的MSSQL文件检测工具对所有数据文件进行检测，发现拼接出的4个NDF文件有大量的空页，其余文件失常。4、进一步对损坏的lun进行剖析，发现这些数据页在存储层面曾经不存在了，这些数据页无奈复原，即这4个文件不能完全恢复。5、数据恢复工程师尝试附加数据库，呈现报错： “解决数据库的日志时出错，如果可能请从备份还原。如果没有可用的备份，可能须要从新生成日志”。6、无日志附加数据库。批改零碎表，从零碎表剔除掉最初增加的LDF文件，计算并批改校验。进行无日志附加数据库，报错：数据库存在一致性谬误。7、批改零碎表中这4个损坏的NDF文件的块数量，使其和复原进去的文件的块数量统一。同时更改这4个NDF文件首页，使得数据库中记录的文件的块数量和拼接进去的NDF的块数量统一，计算并批改校验值。8、无日志附加数据库，报错数据库存在一致性谬误。9、一一批改零碎表中这4个损坏的NDF文件的块数量，使其值等于报错块前一页。剖析报错，因为空页都呈现在这4个NDF前面十几个块中，截断文件对数据完整性影响不大。从新批改零碎表和NDF文件，将数据库中记录NDF块数量的值改至报错的前一页，计算并批改校验。10 、从新进行无日志附加数据库，报错：“因为数据库没有齐全敞开，无奈从新生成日志”。11、批改MDF文件中的数据库的状态值，让数据库认为是齐全敞开的。从新附加数据库胜利。 SQL Server数据库数据恢复后果： 数据库文件胜利附加后，管理员通过数据库中的对象进行初步查问、验证，表中信息根本残缺，数据恢复实现。

服务器数据恢复环境：raid5磁盘阵列；10块磁盘，单盘容量1TB；6号盘是热备盘。 服务器故障：阵列中2块磁盘离线，黄色警报灯亮起。管理员对服务器初步检测，发现阵列磁盘序列号不能读取/无奈通过扩展卡辨认，初步推断磁盘物理故障。管理员分割咱们数据恢复核心进行数据恢复。 服务器raid数据恢复过程：1、服务器数据恢复工程师对故障服务器进行初检，发现该磁盘阵列故障状况比较复杂。失常硬盘和掉线硬盘须要采纳不同的办法解决：失常磁盘可通过数据恢复软件镜像备份，存在物理故障的离线硬盘则须要修复硬件故障后再进行备份。罕用的磁盘故障修复办法为加电检测，判断故障硬盘有无起转、磁头是否寻道，而后通过清洁HDA氧化组件、更换ROM芯片、更换磁头等办法进行修复。本案例中掉线的2块硬盘中的1块磁盘的物理损坏重大无奈修复，只能通过另一块磁盘进行备份和数据恢复。2、判断起始扇区。将不包含热备盘的其余9块磁盘通过数据恢复工具关上，并将镜像文件解析为磁盘，发现该raid5中所有磁盘的0扇区都为“55AA”，0x01C2H处显示“05”代表一个扩大分区，该MBR分区不正确。持续查找发现该阵列在另外1块磁盘中的MBR分区是失常的（0x01C6处数值代表指向的下一个扇区为GPT的头部），根本能够确定该盘是第一块硬盘，GPT分区所在扇区起始于172032扇区，因而初步确定LUN的起始扇区是172032扇区。3、判断raid阵列stripe(条带)大小。stripe(条带)是raid磁盘阵列中用于数据处理的根本单元，条带的大小受raid磁盘阵列影响，剖析条带大小的根据是raid5中每一条带组含一个大小与之相等的校验区。通过查问剖析确定该raid阵列中的条带大小为1024扇区。4、确定磁盘阵列磁盘盘序。该阵列的条带大小为1024扇区，依照此法则进行宰割，使每一条带与记录大小雷同且阵列中所有磁盘全副跳到283123。而后通过比照剖析raid5阵列走向，将曾经剖析进去的第一块硬盘放在第一位即可，理论剖析的阵列盘序为9-3-10-4-2-1-5-8-7。5、重组RAID阵列。借助利用北亚数据恢复核心自主开发的工具将raid阵列进行重组，属性为raid5/Stripe size 512KB/左异步。阵列重组实现后进行数据验证。6、数据验证。对重组好的阵列进行数据验证没有发现问题，本次数据恢复胜利。

虚拟机数据恢复环境：架构在一台DELL服务器上的存储应用FreeNAS来做iSCSI；另外两台DELL服务器做ESXi虚拟化零碎（共5台虚拟机）；FreeNAS是UFS2文件系统，整个存储建一个稠密模式的文件，挂载到ESXi零碎。ESXi虚拟化零碎中最重要的3台虚拟机根本状况：一台windows server零碎，外部数据为该公司的门户网站，ASP.net+PHP混合构架，数据库：SqlServer+mysql。一台为FreeBSD零碎，存储Mysql数据库，供其它多台虚拟机应用。一台为windows server零碎，存储此公司新开发的程序代码。 虚拟机故障状况：一次意外断电后，ESXi零碎连贯不上存储。通过查看后发现FreeNAS中的UFS2文件系统呈现问题。管理员用fsck修复文件系统。修复实现后ESXi零碎能够连上存储，但ESXi零碎不能辨认到原来的数据存储和VMFS文件系统。管理员分割咱们数据恢复核心进行数据恢复。 虚拟机数据恢复过程：本案例的利用构架档次：FreeNAS(UFS2文件系统–> 一个稠密模式的文件) –> ESXi(VMFS文件系统层) -> 单台虚拟机的虚构磁盘 (windows-NTFS文件系统/FreeBSD-UFS2文件系统)。1、镜像FreeNAS层。整个存储的文件就是一个名称为iscsidata的900+GB的文件。2、通过UFS2文件系统的二进制构造，定位到iscsidata文件的Inode数据，数据恢复工程师发现此文件被重建过，inode指针指向的数据量很少。FreeNAS层的问题无奈解决，就无奈进入到下一步的VMFS层剖析。收集UFS2文件系统的重要构造：块大小：16KBSegment大小：2KB柱面组大小：188176KBUFS2一个数据指针占8字节，一个块可存储2048个数据指针，一个二级指针块可存储：2048204816KB= 64GB数据，一个三级指针块可存储64GB*2048= 128TB数据。如果能找到iscsidata文件的三级指针块就能解决FreeNAS层的问题。iscsidata文件重建过，推断有局部指针块已被笼罩。原始iscsidata文件的inode和新建iscsidata文件的 inode就在一个地位，数据恢复工程师尝试搜寻没有发现其它有用的inode，只能编写程序收集有用的指针块： 3、因为iscsidata文件是应用稠密模式，放宽程序的收集条件，收集到大量三级指针块和二级指针块。4、对所有收集到的三级指针块进行剖析，数据恢复工程师发现这些指针块都是有效的，没有发现iscsidata文件应用的三级指针块。数据恢复工程师推断呈现这种状况是因为在新建iscsidata文件时被笼罩（新的iscsidata文件在挂载到ESXi后有个VMFS格式化过程，而本案例中的ESXi版本 应用的是GPT分区，GPT分区会在磁盘最初写入冗余的GPT头和分区表信息数据，这样会应用iscsidata文件的三级指针块）。5、数据恢复工程师剖析收集到的二级指针块，对有大量的二级指针块的指向数据进行DUMP，而后再从磁盘中的数据定位到二级指针。通过这种形式取得大量DUMP的数据。6、剖析VMFS层。因为管理员格式化过VMFS，原始UFS2的指针已失落，VMFS元文件基本上不可用，无重要参考信息。所幸虚拟机都有快照，仍可复原。通过单台虚拟机层(windows(NTFS)和 FreeBSD(UFS2)零碎的文件系统构造)向上定位到VMFS层，再通过VMFS层定位到DUMP出的单个64GB 文件。通过屡次组合，最终将这三台重要的虚拟机的虚构磁盘数据完全恢复进去。7、将复原进去的网页数据和数据库数据上传到新构建的零碎中，拉起利用，没有发现任何问题。历时4天，数据恢复实现。

**MongoDB数据库复原环境：Windows Server服务器；MongoDB数据库。 数据库故障：在未敞开MongoDB数据库服务的状况下拷贝数据库文件到其余分区。拷贝实现后，管理员对原数据库分区进行了格式化，而后将数据库文件拷回格式化的原分区，重新启动MongoDB服务时候发现服务无奈启动。报错如下： 管理员分割咱们数据恢复核心进行数据恢复操作。 MongoDB数据库故障检测：服务没有敞开的状况下间接对MongoDB数据库文件进行拷贝，会导致拷贝进去的mongod.lock文件以及WiredTiger.lock文件谬误。如果删除这两个拷贝进去的文件，再次启动服务，MongoDB会主动从新生成这2个文件。然而检测后发现在拷贝出的数据库文件中，_mdb_catalog.wt文件失落。_mdb_catalog.wt文件里存储了MongoDB数据库中所有汇合的元数据，数据库启动时须要从这个文件中读取相干的信息。这个文件的失落导致数据库无奈获取数据库中汇合对应的名字、汇合的创立选项、汇合的索引信息等元数据，数据库就无奈启动。 MongoDB数据库数据恢复过程：1、数据恢复工程师尝试从文件系统的角度对_mdb_catalog.wt文件进行复原。2、应用数据恢复软件对数据库分区进行扫描，没有发现_mdb_catalog.wt文件的相干信息。依据MongoDB数据库中数据文件的特征值对数据库分区进行扫描，也没有发现_mdb_catalog.wt相干的数据区域。由此判断，_mdb_catalog.wt文件曾经被彻底笼罩毁坏了，无奈复原。3、数据恢复工程师只能设法从数据库的角度提取数据。因为所部署的MongoDB数据库是基于WT存储引擎的，能够应用WT实用工具包提取数据库中的数据。4、首先下载WT实用工具包，而后在windows环境下编译出可执行的wt工具。 5、编译实现后，应用编译好的wt工具对数据库汇合文件中的数据进行荡涤。荡涤实现后，间接读取数据库汇合文件中的数据并写入到一个dump文件中。6、通过这种形式把数据库各个汇合文件中的全副可用数据都提取进去，下一步就是还原数据库环境。7、从新创立一个MongoDB数据库，依据提取出的汇合文件创建对应数量的空集合。而后应用wt工具将提取进去的dump文件一一写入到新创建的空集合中。8、通过查问汇合中的数据，确认这些汇合与元数据库中汇合的对应关系，批改汇合名称，重建索引信息。9、通过查问汇合中的记录，确定记录类型，从而确定fs.files和fs.chunks汇合的地位，批改这两个汇合名称为xxx.files和xxx.chunks后，重建汇合索引，汇合复原实现，能够失常查看其中数据： 数据验证：帮助管理员对全副汇合进行索引重建之后，管理员对数据库整体进行查问验证，确认数据无误，本次数据恢复工作实现。**

服务器Raid阵列故障：某品牌的光纤存储上由14块硬盘组成raid，10号盘和13号盘呈现故障警报，卷无奈挂载，存储无奈工作。管理员分割咱们数据恢复核心要求对存储进行数据恢复并修复其中的数据库。 服务器raid数据恢复过程：1、通过storage manager查看这台存储，发现存储逻辑卷状态失败，阵列中的10号盘和13号盘报告“失败”，6号硬盘报告“正告”，数据恢复工程师只好先通过备份的日志状态对逻辑卷的构造进行剖析，为数据恢复工作获取更多的数据。2、管理员把故障存储上的14块硬盘编号后取出交给数据恢复工程师。数据恢复工程师对这些硬盘进行初检，发现阵列中所有磁盘都能够失常辨认，6号盘smart状态为“正告”状态。3、数据恢复工程师将阵列中所有磁盘状态标记为“脱机”，而后对阵列中的所有磁盘进行镜像备份。在备份的过程中数据恢复工程师发现先前报错的6号硬盘备份的速度非常迟缓，能够判断该盘应该存在大量坏道或者不稳固扇区，须要进行独自解决。4、改用坏道硬盘的镜像工具独自对6号硬盘进行镜像，同时观察镜像的稳固和速度状况。（如果硬盘存在大量的不稳固扇区，能够通过调整磁盘镜像工具的“硬盘镜像设施的响应等待时间”、“遇到坏道跳过扇区的数量”等参数，直到实现所有扇区的镜像）5、实现所有磁盘镜像后查看日志，数据恢复工程师发现1号盘也存在有坏道，10号盘和13号盘也存在大量的不规则坏道。6、数据恢复工程师对文件系统进行逆向剖析获取到raid磁盘阵列中的硬盘盘序、raid校验方向、块大小等根本信息，通过这些信息重组raid。7、实现raid的重组搭建后，数据恢复工程师进一步剖析文件系统，提取出数据库的dmp文件并导入，实现数据恢复。8、数据恢复工程师和管理员先后对复原进去的数据进行验证，没有发现问题，数据恢复胜利。

虚拟机故障：一台Linux操作系统的服务器，EXT4文件系统。每台虚拟机蕴含一个qcow2格局的磁盘文件和一个raw格局的磁盘文件。这台服务器上的KVM虚拟机被误删除，管理员分割咱们数据恢复核心要求复原raw格局的磁盘文件，次要复原的是寄存数据库和程序代码等数据的三台虚拟化服务器。 虚拟机数据恢复过程：1、数据恢复工程师拿到这台服务器的硬盘后对所有硬盘做镜像备份；2、在镜像文件上剖析EXT4文件系统，定位被删除虚拟机磁盘文件的节点地位，获取磁盘文件残留的索引信息；3、校验残留索引信息的正确性，修复毁坏不重大的索引；图为获取的索引等信息： 4、索引修复实现后，解析残留的各级索引，从虚拟机所在的卷中提取虚构磁盘文件；5、依据虚构磁盘文件的提取状况，获取卷中未被索引到的自由空间；6、校验提取进去的磁盘文件的正确性与完整性；7、从自由空间中获取无效信息，尝试对虚构磁盘文件进行修补（如节点，目录项，数据库页等信息）。图为提取出的自由空间： 8、因为索引失落，提取出的虚构磁盘文件并不残缺。针对数据库文件有失落的状况，能够从自由空间中获取数据库页去对数据库文件进行修补，但因为局部页所在区域被笼罩占用，只能尽量多的去补页；9、对于寄存程序代码的服务器中的节点和目录项失落的状况，若节点或目录项有残留，能够尝试去补齐节点和目录项。但局部文件的节点和目录项都失落了。因为节点和目录项之间的相关联，这种状况无奈补齐。因为程序代码文件不具备肯定规律性，如果数据区失落则无奈补齐。图为复原出的局部目录构造： 数据验证：在尽可能的尝试对虚构磁盘文件及其中的数据库文件修补之后，由管理员对数据进行验证。因为上述的起因，数据有小局部失落，然而复原进去重要的数据没有问题，这次数据恢复工作无效。

服务器raid5故障：机房管理员在对机房服务器进行定期维护过程中误操作导致一台服务器（raid5磁盘阵列）中的分区失落。因为失落的分区存储了该公司所有的生产业务数据，从而导致业务中断。管理员分割咱们数据恢复核心进行数据恢复。 服务器raid5故障检测和复原计划：咱们数据恢复核心的数据恢复工程师对服务器进行检测，发现该服务器文件系统头部的超级块及局部节点、目录项失落。依据超级块备份及文件系统中的目录树结构，数据恢复工程师对超级块进行修复还原，对失落的节点、目录项进行修补、重构之后，文件系统应该能够残缺复原。 服务器raid5磁盘阵列数据恢复过程：1、数据恢复工程师对所有的硬盘进行镜像，备份实现后将原服务器交还机房管理员；2、应用自主开发的服务器数据恢复工具对备份进去的数据进行解析，获取该磁盘阵列的盘序法则、条带大小等复原数据所须要的raid信息；3、利用获取到的raid信息重组raid5磁盘阵列，而后定位xfs文件系统的分区起始地位；4、服务器数据恢复工程师对该文件系统的完整性和文件系统的正确性进行校验，结果显示xfs文件系统头部超级快失落、局部节点失落、目录项失落；5、依据超级块备份及文件系统中的目录树结构，对超级块进行修复还原；对xfs文件系统中失落的节点及目录项进行修复；对失落的节点、目录项进行修补、重构（过程略）；6、实现上述的修复后，数据恢复工程师编写小程序对文件系统进行解析和数据提取； 7、提取实现后让管理员对复原进去的数据进行检测验证，确认数据残缺无误。

数据库数据恢复环境：5块2T硬盘组建RAID5；划分LUN供windows服务器应用；Sql Server2008数据库；存储空间有三个逻辑分区。 数据库故障：数据库文件失落，波及到5个数据库，表约6000个，失落起因未知，且不能确定数据存储地位。在文件失落后服务器仍处于开机状态，但并未写入大量数据。 初检流程：1、应用RAID信息及外部数据块信息重组RAID。 重组RAID 2、提取LUN内三个分区镜像。3、扫描文件系统内失落文件，未找到被删除数据库文件。4、初检后果为数据库文件失落，通过文件系统无奈复原。 数据库复原流程：1、制订复原计划。在数据库文件被删除且断定为无奈复原文件后，只能通过扫描数据页，并提取页内记录的形式进行复原。2、应用北亚自主编写的数据页扫描程序扫描分区内数据页并提取。在别离扫描两个分区镜像后发现500G零碎盘内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页个数较多。暂定此分区为数据库文件存储空间。 扫描数据页 3、重组零碎表。Sql Server数据库应用零碎表来治理所有用户表，在这些零碎表内记录了各表的列数、数据类型及束缚信息等。解析零碎表过程中发现提取出的数据页内零碎表损坏，无奈失常读取信息。在与管理员沟通后得悉有备份文件，且备份实现后没有大量改变表构造，零碎表可用。4、还原备份。 还原备份 5、别离提取三个库中各表的表构造信息。 提取表构造信息 6、解析表构造脚本。将各表的列信息存入数据库内便于后续应用。 扫描脚本文件 表构造信息存入数据库 7、解析零碎表获取用户表id信息、关联表构造与数据页。（为爱护隐衷，后续步骤波及用户表表名及数据页内数据局部均未截图）8、新建数据库，应用北亚自主编写软件解析记录并导入到复原环境内。9、整顿复原后果。在此分区内除数据库文件外还存有备份文件若干，所以在导出记录后可能存在反复数据，必须去重。数据恢复工程师编写SQL存储过程进行去重。 数据库去重 10、验证数据。管理员在查验过数据后示意没有问题，移交数据到管理员筹备好的存储设备，复原胜利。

raid故障状况：一台光纤存储共有16块硬盘，存储的卷无奈挂载。管理员查看存储设备发现有2块硬盘离线，raid解体。管理员分割北亚数据恢复核心对存储进行数据恢复。 raid数据恢复过程：1、服务器数据恢复工程师对以后的存储状态进行查看，通过storage manager把存储目前的日志状态进行备份。而后依照存储内的硬盘程序将硬盘移出存储设备。2、数据恢复工程师将所有硬盘挂载到Windows环境下，将硬盘状态变更成为“脱机”，将所有硬盘进行扇区级备份。3、对存储的镜像文件进行剖析查问，服务器数据恢复工程师发现阵列中的1号硬盘、10号硬盘、13号硬盘存在大量的不规则坏道，严重破坏了EXT3文件系统的关键性源数据信息。这种状况下无奈间接通过镜像复原存储内的数据，只能通过同一条带进行XOR同时依据ext3文件系统的文件构造对被毁坏了的信息进行手动修复。4、剖析文件系统的日志文件获取到这台存储内所有磁盘的盘序、raid块大小、raid的校验走向等数据恢复所须要的raid根本信息。利用这些信息重组raid磁盘阵列。5、阵列重组实现后进一步解析文件系统。因为存储中的次要数据为oracle数据库，数据恢复工程师尝试通过提取dmp文件复原数据库。6、实现提取dmp文件后，数据恢复工程师将提取进去的dmp文件导入验证，没有发现任何问题，一切正常。本次数据恢复工作实现。 数据安全小贴士：在服务器产生故障后，需注意以下几点：1、服务器产生故障后，用户切忌再对服务器进行任何操作，也切忌随便取出硬盘，免得弄乱程序减少前期数据恢复的难度。2、如果曾经取出硬盘，标记好硬盘的程序。3、求助业余正规的服务器数据恢复公司，切忌随便交给不出名的小数据恢复公司。4、如果单位服务器内存储的是保密度较高、或者较为重要的数据资料，倡议装备单位外部服务器数据恢复设施，防止在进行服务器数据恢复的过程中造成数据泄密。

服务器数据恢复环境：DELL PowerEdge服务器；6块SCSI硬盘组成RAID5；LINUX REDHAT操作系统； EXT3文件系统。 服务器故障状况：服务器运行过程中有一块硬盘离线，但服务器管理员未及时发现，直到另一块硬盘掉线服务器解体。管理员分割DELL工程师寻求帮忙，DELL工程师倡议将其中一块硬盘强制上线，并明确示意本操作具备肯定的危险。管理员将其中一块掉线盘强制上线后，发现操作系统启动异样。于是分割咱们数据恢复核心进行数据恢复。 服务器故障剖析：此类服务器故障在咱们数据恢复核心接到的案例中常常见到。因为RAID5仅反对一块硬盘掉线的冗余爱护。如果有两块硬盘离线，RAID5无奈通过运算提供残缺数据块，阵列便会解体。可能是为了稳固起见，RAID控制器还有一个特点：只有有硬盘下线，备份盘不会主动上线。如果不通过人为操作，RAID5会进入瘫痪状态。通常状况下， 控制器的高敏感性决定少数掉线硬盘不会有重大的物理故障，很多状况下掉线硬盘是完整无缺的。尽管这种状况让数据恢复的胜利可能性很高，然而强制上线依然具备较大危险。因为上线谬误会导致控制器主动做出一些不可逆的操作。这种状况下进入操作系统，文件系统的不统一会触发主动修复，从而导致全副硬盘的数据不统一。本案例就是这种状况。 服务器数据恢复过程：1、给所有硬盘做镜像，镜像过程中发现多块没有掉线的硬盘也存在坏道，只是RAID还没有辨认进去，临时没有下线。2、在镜像中剖析RAID获取RAID相干信息，依据获取到的RAID信息构建RAID环境。3、验证RAID构造，修改局部毁坏的构造，将数据导出到另一存储。4、用完整的硬盘在DELL PowerEdge服务器搭建的RAID5。 5、将复原进去的数据迁徙至新搭建的RAID上。6、通过管理员亲自验证，复原进去的数据没有发现问题。 北亚数据恢复服务：1、收费检测；2、签订窃密协定(非定制收费)，对数据严格窃密；3、数据恢复不胜利不免费；4、工程师提供服务，其余工程师审核、会诊数据恢复计划及流程；5、数据恢复前报价，客户确认后工程师开始数据修复；6、整个复原过程不会对客户的原盘有任何的写操作，以确保原盘的数据齐全。

服务器故障：服务器管理员误操作删除了XenServer服务器中的一台虚拟机，这台服务器中存储了公司重要数据，于是分割咱们数据恢复核心进行虚拟机的数据恢复。数据恢复工程师返回现场初检发现服务器内的VPS不可用，虚构磁盘中的数据失落。通过沟通由数据恢复工程师携带数据恢复设施返回现场进行数据恢复。 服务器数据恢复过程：1、数据恢复工程师将服务器所有硬盘进行扇区级镜像，确保原服务器内数据安全。2、对底层数据进行剖析。原服务器内虚拟机磁盘构造为LVM，虚拟机磁盘为精简模式。排查底层数据发现了局部尚未被更新的lvm信息。 3、剖析查找到的lvm信息，尝试还原虚构磁盘数据区，然而虚构磁盘数据区少数数据被毁坏，只有数据库页碎片保留下来了。4、北亚数据恢复工程师应用拼接碎片的形式还原被毁坏的数据库。剖析数据库的起始地位，而后从头开始顺次扫描合乎数据库页的数据碎片，最初利用这些数据库页碎片按程序重组成一个残缺的mdf文件并校验文件完整性。 5、Mdf文件校验通过后，由数据恢复工程师搭建一个新的数据库环境。把刚复原出的mdf文件附加到刚刚搭建好的数据库环境中，查问相干表的最新数据状态。通过查问所有数据失常，最近数据残缺。 数据验证：服务器内的数据恢复实现后，由服务器管理员对所有数据进行验证，通过验证确认所有数据均曾经复原胜利。因为本案例服务器底层的大量数据受到破坏，无奈通过惯例形式进行数据恢复，只能抉择难度较大的拼碎片形式复原。

数据恢复环境：Oracle 11g R2数据库。 数据库故障状况：数据库管理员误truncate table CM_CHECK_ITEM_HIS，表数据失落，业务查问到该表时报错。数据库备份不可用，表数据无奈查问。 *Oracle数据库小常识：Truncate原理：ORACLE会在数据字典和Segment Header中更新表的Data Object ID，而理论数据局部的块则不会做批改。因为数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不统一，所以ORACLE服务过程在读取全表数据时不会读取到曾经被TRUNCATE的记录。 Oracle数据库数据恢复过程：1、为爱护用户的数据，本文档模仿构建与用户生产环境雷同的故障。Scott用户创立表emp1，复制emp表，间断复制屡次，总记录数为：7340032条。truncate表emp1，之后没有进行任何操作。查问该表，数据库中该表的记录为0条。 注： Os：win server 2008R2。数据库版本：win_oracle_11.2.0.1_x64; 2、对system表空间文件进行剖析，找到truncate表的原始数据所在的地位。 3、解析表所在的数据文件，找到truncate的数据。 4、将truncate的数据插入到数据库中。 总结：通过解析system01.dbf文件，北亚数据恢复工程师找到truncate的数据所在的地位，找到被删除的数据。解析表所在的数据文件，将truncate的数据插入到数据库中。 在数据库中，查找被truncate，发现数据回来了，间接备份数据。 5、Exp导出scott用户。

虚拟化数据恢复环境：Linux零碎，EXT4文件系统；每台虚拟机蕴含1个qcow2格局的磁盘文件+1个1.2T的raw格局的磁盘文件。 虚拟机故障：KVM虚拟机被机房管理员误操作删除掉了。须要复原的是raw格局的磁盘文件，次要是三台虚拟化服务器，寄存的是数据库，程序代码等数据。 虚拟机数据恢复过程：1、剖析EXT4文件系统，定位被删除虚拟机磁盘文件的节点地位；2、获取磁盘文件残留的索引信息；3、校验残留索引信息的正确性，修复毁坏不重大的索引；4、修复实现后，解析残留的各级索引，从虚拟机所在的卷中提取虚构磁盘文件；5、依据虚构磁盘文件的提取状况，获取卷中未被索引到的自由空间；6、校验提取出的磁盘文件的正确性与完整性；7、从自由空间中获取无效信息，北亚数据恢复工程师尝试对虚构磁盘文件进行修补（如节点，目录项，数据库页等信息）。 虚拟机数据恢复后果：1、因为索引失落，提取出的虚构磁盘文件并不残缺，针对数据库服务器，数据库文件有失落的状况，能够从自由空间中获取数据库页去对数据库文件进行修补，但因为局部页所在区域被笼罩占用，只能尽量多的去补页；2、对于寄存程序代码的服务器中的节点和目录项失落的状况，若节点或目录项有残留，能够尝试去补齐节点和目录项，但发现局部文件的节点和目录项同时失落。依据节点和目录项之间相关联的个性，这种状况下无奈补齐。依据程序代码文件的个性，不具备肯定的规律性，若其数据区失落，无奈补齐。 数据验证及后果：在尽可能的尝试对虚构磁盘文件及其中的数据库文件修补之后，由服务器管理员对数据进行验证。数据有小局部失落，整体能够承受，数据恢复无效。

服务器数据恢复环境：6块750G磁盘的RAID6；WEB服务器+MYSQL数据库；寄存了大量其它文件。 服务器故障：先后有两块磁盘离线，服务器管理员没有及时更换磁盘，当第3个硬盘离线后raid解体，数据全副失落。服务器管理员在数据失落后便第一工夫分割一家当地的数据恢复公司，然而通过该公司的数据恢复操作后仍有近一个月的文件没有复原进去，MYSQL数据库依然没有修复好。起初经其余运维的介绍，这位服务器管理员就分割到了咱们数据恢复核心。 服务器数据恢复过程：1、通过和服务器管理员沟通具体理解服务器故障后，咱们数据恢复核心的数据恢复工程师先将这6块磁盘镜像备份到咱们复原核心的平安存储池中，当前数据恢复操作只会在镜像备份上进行。2、通过对服务器备份镜像的剖析，数据恢复工程师发现其中2块磁盘离线工夫较早，没有写入最新的数据。本案例中的RAID6用的是双校验，第一个校验是由一般的XOR运算生成，而第二个校验是由Reed-Solomon算法生成。本案例RAID6有两块磁盘早已不写入新数据，要想残缺复原数据就必须应用第二个校验，否则最新的数据会失落。3、数据恢复工程师剖析原始RAID的一些参数，而后应用北亚数据恢复工程师本人编写的RAID6复原软件生成出一个残缺镜像，再将镜像导回服务器管理员用新搭好的存储环境上，开机一切正常。4、通过服务器管理员亲自验证，数据无任何问题，本次服务器数据恢复实现。

服务器数据恢复环境：10个磁盘柜，每个磁盘柜24块硬盘；9个存储柜存储数据，1个存储柜存储元数据；元数据存储柜中的24块硬盘配置状况：9组RAID1阵列+1组4盘位RAID10阵列+4个全局热备硬盘。数据存储柜中硬盘配置：共36组6盘位的RAID5，分为2个存储系统。 服务器故障：数据存储柜的1个存储系统中的一组RAID5因为2块硬盘先后故障离线，RAID阵列生效，整个存储系统解体，无奈应用。存储及文件系统架构大抵如下： 注：Meta_LUN(元数据卷) Data_LUN（用户数据卷） 服务器数据恢复过程：1、为了避免服务器数据恢复操作对原始磁盘数据造成二次毁坏, 首先对存储中所有硬盘进行备份。备份过程如下： 对故障RAID中的6块盘进行编号标记，将硬盘从存储柜中插入接入到备份服务器上进行备份。对没有呈现故障的RAID阵列进行存储层面的备份。应用光纤线缆将备份平台和存储设备连贯，进入存储设备治理界面配置备份平台和存储设备让2者能够失常通信，应用软件对RAID中的LUN进行镜像备份。在备份过程中发现故障RAID中的1块硬盘存在大量的坏道，在备份的过程呈现谬误，无奈持续备份。对故障硬盘收盘更换固件，应用工具对其进行修复后持续备份，但坏道依然存在。局部镜像文件： 2、RAID数据分析。对故障RAID进行剖析获取相干RAID信息，应用软件对RAID阵列进行虚构重组，并将RAID中的LUN复原成镜像文件。在剖析过程中发现，损坏较重大的硬盘为后离线硬盘，因为此硬盘存在大量坏道，可能对最初的复原后果产生肯定的影响。 3、登录存储设备治理界面，获取到StorNext文件系统中卷的相干信息。 4、持续对StorNext文件系统中的Meta卷和Data卷进行剖析。本案例的StorNext文件系统蕴含2个Data卷，每一个残缺的Data卷都是由多组RAID中的LUN组成的。对这些LUN进行剖析获取到LUN之间组合的算法法则，虚构重组出残缺的Data卷。 5、剖析Meta卷。对Meta卷中的节点信息、目录项信息以及Meta卷和Data之间的对应关系进行剖析，针对一个Meta卷治理多个Data卷的状况钻研获取到Meta卷到Data卷的索引算法。 文件节点如下： 目录块如下： 6、扫描解析数据。通过后面的剖析钻研曾经获取到了数据恢复工作所需的全副信息。北亚数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息，同时对目录项和节点进行解析，获取残缺的文件系统目录构造，解析每一个节点中的指针信息，将这些信息记录在数据库中。 7、提取数据。编写文件提取程序读取数据库，依据解析出的信息以及两个Data卷之间的聚合算法对数据进行提取。 8、数据检测验证。对复原进去的数据进行随机抽样检测没有发现问题。将用户所需全副文件提取到本地进行数据移交。用户对复原进去的数据进行验证后确认复原进去的数据残缺无误。

服务器数据恢复环境：Dell PowerVault系列磁盘柜；用RAID卡创立的一组RAID5；调配一个LUN。 服务器故障：在Linux零碎层面对LUN进行分区，划分sdc1和sdc2两个分区。将sdc1通过LVM扩容的形式退出到了root_lv中，将sdc2分区格式化为XFS文件系统。服务器管理员在为服务器重装系统后，发现磁盘分区扭转，原先的sdc2分区失落，无法访问。 服务器数据恢复过程：为避免数据恢复操作对原始磁盘造成二次毁坏，数据恢复工程师为服务器中的每块磁盘做镜像，之后所有的数据恢复操作都在镜像盘上进行。1、基于磁盘镜像剖析raid的盘序、条带大小等raid信息；2、利用获取到的raid信息虚构重组出raid构造；3、定位到xfs文件系统的分区起始地位；4、校验xfs文件系统的完整性及正确性；5、对失落的xfs文件系统进行检测后发现，文件系统头部的超级块及局部节点、目录项失落，依据超级块备份及文件系统中的目录树结构，对超级块进行修复还原，对失落的节点、目录项进行修补、重构之后，文件系统中的数据基本上能够残缺复原；6、修复xfs文件系统的超级块构造； 修复实现的超级块 7、对xfs文件系统中失落的节点及目录项进行修复； 修复实现的根节点 重做的目录项 8、修复实现后，北亚数据恢复工程师编写程序解析xfs文件系统，提取其中的数据； 修复实现的目录构造 9、数据恢复工程师和服务器管理员别离对复原进去的数据进行测验，确认复原进去的数据残缺可用。

最近一段时间碰到了好几个意外断电引起的服务器故障而导致的数据失落的案例。意外断电引起的服务器故障有：服务器无奈启动、服务器能够启动然而虚拟机失落、服务器多块硬盘呈现故障离线……（如同最近机房的供电都不太稳固的样子）。明天咱们通过一个异样断电导致服务器数据失落的案例给大家简略介绍一下服务器异样断电如何进行数据恢复，仅供技术交换，如果有更好的办法欢送探讨。 服务器数据恢复环境： 服务器故障： 忽然断电导致服务器上的一台虚拟机不可用。 服务器故障剖析： 数据恢复第一要务：所有的数据恢复操作之前都必须将原始数据在数据恢复服务器上进行镜像备份，而后只能在镜像文件上进行数据分析与数据恢复操作，切忌不可对原服务器做任何操作，放弃原服务器数据的初始状态。 通过数据恢复工程师的剖析发现原服务器中失落的虚拟机磁盘采纳了LVM构造，在“/etc/lvm/backup/”目录下查问看有没有损坏的虚拟机磁盘的信息，如果有就阐明LVM信息尚有保留；如果查问没有就阐明该信息曾经被更新，只能在底层数据中查问看有没有更新的lvm信息。本案例就是从底层数据中查问到了尚未更新的lvm信息，请见下图： 找到lvm信息就阐明数据还在，以lvm信息为根底进行剖析查找虚构磁盘的分区数据。然而通过数据恢复工程师的剖析发现本案例中的虚构磁盘被毁坏掉了。通过服务器数据恢复工程师的进一步查找和剖析发现该区域的数据的确被毁坏了，仅找到一些数据库页碎片。如果想要胜利复原数据就只能通过拼接数据库碎片这种办法了。 服务器数据恢复操作：*rar压缩包的构造：失常状况下rar压缩包的第一个扇区记录的是文件名，能够依据文件名反向剖析压缩包的数据起始地位，而后把相应的压缩包底层数据提取进去并重命名。1、在本案例的实际操作过程中却出了意外：提取进去的压缩包解压时报错，报错信息如下： 2、因为解压数据报错，服务器数据恢复工程师首先尝试应用rar修复工具（设置为疏忽谬误）进行修复，然而解压仍旧失败。3、在数据库层面剖析数据库开始地位，因为咱们曾经晓得了数据库名称，能够由此反推数据库开始地位。4、依据每个数据库页的编号和文件号去底层数据扫描合乎这个数据库页的所有数据。5、北亚数据恢复工程师把所有扫描进去的数据拼接重组为一个mdf文件，重组后的mdf文件如下图所示：  6、通过校验程序对重组进去的数据进行检测。7、检测合格后服务器数据恢复工程师进行数据提取操作。8、数据恢复工程师搭建了一个数据库环境，将复原进去的数据库数据附加进去进行查问，确认复原进去的数据失常。本服务器数据恢复胜利，复原后果见下图：

服务器数据恢复环境： 一台服务器应用FreeNAS做iSCSI，借助两台服务器做虚拟化零碎；FreeNAS采纳UFS2文件系统；整个服务器建一个文件挂载给ESXi零碎；ESXi虚拟化零碎有5台虚拟机：一台虚拟机部署了ASP.net和PHP，SqlServer2005和 mysql5.1两个数据库；另一台装置FreeBSD零碎，MySQL数据库；第三台虚拟机存储的是代码数据，这三台虚拟机上的数据是须要重点复原的。 服务器故障： 须要进行数据恢复的服务器在失常运行过程中意外断电，重启后虚拟化零碎无奈连贯服务器，FreeNAS中UFS2文件系统呈现问题。服务器管理员对文件系统进行了修复，然而ESXi零碎不能辨认原有数据和文件系统，分割我数据恢复核心进行服务器数据恢复。 服务器数据恢复过程： 此服务器数据恢复案例的利用构架档次：FreeNAS(UFS2文件系统–> 一个大的稠密模式的文件) –> ESXi(VMFS文件系统层) -> 单台虚拟机的虚构磁盘 (windows-NTFS文件系统/FreeBSD-UFS2文件系统)。 1、镜像FreeNAS层并剖析整个存储，只发现一个900多GB的文件名为iscsidata的大文件。通过UFS2文件系统的二进制构造定位到iscsidata文件的Inode数据发现此文件被重建过，inode指针指向的数据量很少。FreeNAS层问题无奈解决，就无奈进入到下一步的VMFS层剖析。 2、收集UFS2文件系统的重要构造：块大小：16KBSegment大小：2KB柱面组大小：188176 KBUFS2一个数据指针占8字节，一个块可存储2048个数据指针。那么一个二级指针块则可存储：2048204816KB=64GB的数据。一个三级指针块则可存储64GB*2048=128TB的数据。如果能找到iscsidata文件的三级指针块就能解决FreeNAS层问题。但iscsidata文件重建过，过程和大小都和原始的一样，初步判断有局部指针块已被笼罩。原始 iscsidata文件的inode和新建的iscsidata文件的inode就在一个地位。 3、尝试进行搜寻没有发现其它有用的inode，数据恢复工程师只得现场写程序收集有用的指针块：* 因为iscsidata文件采纳的是稠密模式，收集条件只能放宽，收集到了大量三级指针块和二级指针块。 4、对收集到的所有三级指针块进行剖析，没有发现iscsidata文件应用的三级指针块，初步判断在新建iscsidata文件时被新的笼罩（新的iscsidata文件在挂载到ESXi后有个VMFS格式化过程，而ESXi应用GPT分区，GPT分区会在磁盘最初写入冗余的GPT头和分区表信息数据，这样就会应用iscsidata文件的三级指针块）。 现只能剖析收集到的二级指针块，对有大量的二级指针块的指向数据进行DUMP，而后再从磁盘中的数据定位到二级指针。这样失去大量DUMP的数据。 5、剖析VMFS层。重格式化过VMFS，原始UFS2的指针已失落，VMFS元文件基本上不可用，无重要的参考信息，所幸虚拟机都有快照，仍可复原。通过单台虚拟机层(windows(NTFS)和 FreeBSD(UFS2)零碎的文件系统构造)向上定位到VMFS层，再通过VMFS层定位到DUMP出的单个64GB 文件，通过屡次组合，最终将这三台重要的虚拟机的虚构磁盘完全恢复。将复原进去的网页数据和数据库数据上传到新构建的零碎中，利用运行没有发现问题。通过3天的致力，服务器内的所有数据被胜利复原。

服务器数据恢复环境：HP ProLiant系列服务器；6块73GB的SAS硬盘组成的RAID5；操作系统：WINDOWS SERVER；存储文件：企业的外部文件，无数据库文件。 服务器故障：因为没有装备UPS，服务器遇到几次意外断电，然而重启后没有出现异常，直到最近一次断电重启后RAID报错，无奈找到存储设备，进入到RAID治理模块进行操作导致死机。服务器管理员屡次尝试重启服务器，然而没法进入零碎。 服务器故障剖析：本案例是典型的服务器意外断电导致的RAID模块损坏（包含RAID治理信息失落和RAID模块硬件损坏）。个别在RAID阵列创立实现后，阵列的治理模块信息就会固定下来不再产生扭转，然而阵列的模块信息是能够批改的。服务器意外断电很容易造成阵列的模块信息被篡改甚至失落，屡次断电甚至有可能造成RAID卡上的元器件损坏，使主机失去对多块物理硬盘进行RAID治理的中间层模块。该案例中对RAID模块的操作导致死机极有可能是因为RAID卡硬件损坏，应用惯例办法无奈获取6块硬盘中的数据，只能通过业余的数据恢复操作来复原原先的数据。 服务器数据恢复过程：1、首先对原服务器内所有硬盘进行物理故障检测，查看硬盘是否有硬件故障。检测后发现服务器内所有硬盘均能够失常读取，没有发现存在物理故障。2、对服务器内的所有硬盘进行镜像备份。3、镜像实现后，服务器数据恢复工程师剖析raid构造，确定raid阵列的硬盘程序、数据块的大小和阵列校验形式等raid信息。4、服务器数据恢复工程师利用剖析获取到的raid阵列信息虚构重建一组RAID并进行逻辑校验，确认重构的RAID所利用的各项参数正确无误后，针对服务器管理员最为关注的数据进行验证；5、数据恢复工程师分割服务器管理员对复原进去的数据进行验证，通过验证后所有数据均胜利复原；6、把数据迁徙到服务器管理员从新搭建进去的和原服务器一样的环境中，通过测试后一切正常。 服务器数据安全小贴士：1、保障机房供电稳固，尽量减少供电异样对主机及存储的影响；2、为要害的服务器和存储配置UPS，在机房意外断电的状况下保障外围业务零碎能持续维持失常工作，为其余应急计划的施行争取时间；3、对于应用工夫长的服务器应定期进行安全检查，对其整体运行状态进行评估，是否对其进行硬件及零碎的降级；4、提前制订突发数据劫难的应急解决计划，缩小数据劫难带来的损失。

服务器数据恢复环境： 6块SAS硬盘中的5块硬盘组成一个RAID5的阵列，1块作为热备盘应用。 服务器故障： RAID5中1块硬盘故障，热备盘激活开始同步数据，在同步数据过程中又有一块硬盘故障离线，导致RAID5瘫痪，下层LUN无奈失常应用。 服务器故障检测和备份： 1、检测磁盘。初步判断是RAID阵列中某些磁盘掉线导致存储不可用。因而在接管到磁盘当前先对所有磁盘做物理检测，检测发现只有一块硬盘有物理故障。2、备份数据。将所有磁盘都镜像成文件，备份过程中也没有发现其余磁盘物理故障。 服务器故障剖析： 1、剖析故障起因因为IBM存储控制器对于磁盘的检测策略很严格，磁盘性能不稳固也会被IBM存储控制器断定为坏盘并踢出RAID组。因而检测出的故障磁盘有可能是读写不稳固，也有可能存在物理故障。而一旦RAID中掉线盘数超过这组RAID自身容许掉盘的最大数量，那么这个RAID组将不可用，基于RAID组的LUN也将不可用，因而导致数据失落 2、剖析RAID组构造IBM存储的LUN都是基于RAID组的，因而须要先剖析底层RAID组的信息，而后利用剖析获取到的信息重构原RAID组。剖析每一块数据盘，如果那块盘的数据同其它数据盘不太一样，能够初步认定为HotSpare盘。剖析其余数据盘，剖析Oracle数据库页在每个磁盘中散布的状况，并依据数据分布的状况得出RAID组的条带大小，磁盘程序及数据走向等RAID组的重要信息。 3、剖析RAID组中的LUN信息因为LUN是基于RAID组的，因而须要根据上述获取到的信息将RAID组虚构重组进去，而后剖析LUN在RAID组中的分配情况，以及LUN调配的数据块MAP。只须要将LUN的数据块散布MAP提取进去。而后针对这些信息编写相应的程序，对LUN的数据MAP做解析，而后依据数据MAP导出LUN的数据。 服务器数据恢复解决方案： 1、实施方案一对复原的蕴含Oracle数据库的LUN进行JFS2文件系统解析，并对文件系统不残缺的局部进行人工修复。利用北亚自主开发的JFS2文件系统解析工具解析复原的LUN，而后复原文件系统中所有的Oracle数据库文件，并检测Oracle数据库的文件是否残缺。对检测有坏块的数据库文件所在磁盘进行扫描Oracle碎片操作，将扫描到的数据页进行组合，而后将有坏块的数据库文件通过人工的形式填补修复残缺。在实现所有Oracle数据库文件的复原之后，利用SAP还是无奈失常应用。SAP利用的一些重要数据寄存在损坏的存储中，缺失这些数据会导致SAP即便在数据库残缺的状况下也无奈失常应用，因而还需采纳计划二来复原所有SAP的重要数据。 2、实施方案二对复原进去的所有LUN进行文件系统解析，将蕴含SAP的数据LUN进行文件系统的一致性检测。对文件系统不残缺的局部进行人工修复，最初复原所有SAP及SAP Test的数据。对SAP的数据进行检测，并对损坏的数据进行修复，确保复原进去的SAP数据是残缺的，这样能力保障SAP利用可能残缺启动。利用复原的SAP数据联合之前复原进去的Oracle数据库，即可启动SAP及所有利用。 启动并修复Oracle数据及SAP利用： 1、启动Oracle数据库并修复把复原进去的数据库文件还原到已搭建好的环境中，并尝试启动数据库。在启动过程中因为数据库的一些临时文件校验不统一导致数据库启动失败。协调Oracle数据库工程师近程对数据库进行修复后，数据库失常启动，数据残缺，而后尝试启动SAP。 2、启动SAP并修复将复原的SAP文件还原至已搭建好的环境中，并依照之前的启动脚本启动SAP，SAP启动失常，但SAP中用户权限及应用不失常，SAP体现为没有序列号。初步判断是SAP的注册文件没有复原，从新检测复原过程，排查可能出问题的局部。排查后发现是因为文件系统的损坏而导致某些文件没有复原胜利。从新修复文件系统，复原这些数据。启动SAP失常，应用失常。 数据验证： 启动Oracle数据库，启动SAP，通过SAP客户端验证SAP中所有的数据，数据恢复残缺，SAP能失常应用。

Oracle数据库故障：ASM磁盘组掉线，ASM实例不能mount。数据库管理员尝试进行简略的数据库修复然而没有胜利。Oracle数据库数据恢复计划：数据库数据恢复工程师对底层的磁盘进行剖析。剖析组成ASM磁盘组的磁盘。将ASM元数据提取进去进行剖析发现ASM存储元数据曾经被损坏，因而导致diskgroup无奈mount。数据库数据恢复工程师对ASM存储空间进行重组，而后把ASM磁盘组外面的数据库文件导出，对导出的数据库文件进行检测和复原。如果导出的数据库文件通过检测确定数据文件是残缺的，那么就能够间接利用数据库文件启动数据库即可；如果数据库文件被损坏，那么须要对底层的数据库文件进行解析之后复原。 Oracle数据库数据恢复过程：1、首先依照上述计划对底层数据进行剖析和提取，获取ASM元数据，而后利用ASM元数据重组出ASM存储空间。2、ASM存储空间重组实现后，数据库数据恢复工程师应用北亚ASM解析工具进行ASM构造解析，最终目标是获取到ASM中的数据文件。3、对提取出的数据库文件进行检测，检测后果如下图：4、应用数据恢复核心自主开发的oracle数据库解析工具解析所有数据文件中的数据记录，而后按用户导入到新的数据库中，如下图所示：5、数据库数据恢复工程师通过抽查数据表的形式对复原进去的数据进行验证，没有发现异常。而后让服务器管理员亲自验证数据，确认数据恢复后果残缺可用，Oracle数据库数据恢复胜利。

服务器数据恢复环境：一台PowerEdge R系列服务器和一台PowerVault数据存储；下层是虚拟机，虚拟机零碎为ESXI。 服务器故障：机房非正常断电导致虚拟机不能启动。服务器管理员对虚拟机进行了查看发现虚拟机配置文件失落，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还存在。 服务器管理员在试图复原虚拟机的时候将原虚拟机内的xxx-flat.vmdk删除而后新建了一个虚拟机，调配了200GB的精简模式和160GB的快照数据盘，然而原虚拟机内的数据并没有复原。服务器管理员分割咱们数据恢复核心进行虚拟机数据恢复。 虚拟化数据恢复过程： 1、将挂载在VMware vSphere Client上的卷卸载后备份。2、通过数据恢复工程师对备份数据进行检测和剖析发现虚拟机目录项因为非正常断电被毁坏，服务器管理员删除操作导致文件的数据区索引被革除，重建虚拟机导致调配给新建虚拟机的磁盘数据底层被清零。虚拟机目录项和文件的数据区索引能够通过人工修复形式进行复原数据，但新建虚拟机的操作导致底层数据清零，如果新建虚拟机磁盘的空间占用了原虚拟机的开释空间则会导致这部分数据无奈复原，具体须要进一步检测。虚拟机数据恢复案例之虚拟机目录项： 3、虚拟化数据恢复工程师对底层数据进行剖析，在自由空间内排查被删除的虚拟机磁盘区域，对这部分区域进行扫描发现了大量的碎片。数据恢复工程师对碎片进行重组，通过拼接和重组后发现缺失局部碎片文件，只能临时将失落的文件碎片地位留空。 4、虚拟化数据恢复工程师利用虚构磁盘快照程序将重组好的父盘和快照盘进行合并，生成一个新的虚构磁盘。利用工具解释虚构磁盘中的文件系统，因缺失好多数据，文件系统解释过程中频繁报错提醒文件损坏。解释完的文件系统如下图：虚拟机数据恢复案例之文件系统解释后果： 5、解析完文件系统后发现没有找到原始的数据库文件，而备份和备份这两个目录的目录构造失常。然而在尝试将备份导入数据库中时，数据库导入程序提醒报错。备份和备份的局部目录构造如下图：虚拟机数据恢复案例之目录构造： 6、导入.BAK文件报错信息如下: 7、虚拟机数据恢复工程师依据SQL Server数据库的构造去自由空间中找到数据库的开始地位。数据库的库名通常呈现在以后库的第九页内，依据这一个性能够借助一些数据恢复工具到底层扫描数据库页的碎片，再利用数据库碎片重组mdf文件，在本次数据恢复案例中除了cl_system3.dbf和erp42_jck.dbf因有局部碎片没有找到外（极有可能这部分数据被笼罩了），其余数据库文件均校验胜利。校验完的MDF文件如下：cl_system3.dbf文件中某个碎片失落的区域如下图： 8、虚拟机数据恢复到这一步曾经将可用的数据都利用得差不多了，然而数据仍然没有复原残缺，最初只能依附备份文件。数据恢复工程师对备份文件进行具体的查看后发现这两个失落的文件仍然不存在，只有局部增量备份文件。 9、因为erp42_jck.dbf文件中只缺失大量的页，因而能够依据缺失的页号在增量备份中查找，将找到的页补到erp42_jck.dbf文件中，通过这种形式能够复原一部分失落的数据库页。然而补完后还是缺失局部页，无奈失常应用。 10、虚拟化数据恢复工程师通过北亚数据恢复核心自主开发的数据库解析程序将erp42_jck.dbf文件中用户比拟重要的几十张表胜利导出，并胜利导入到新建的数据库中，复原进去缺失的文件。 虚拟化数据恢复数据验证： 在数据恢复安全设备中从新搭建原始环境，将复原进去的数据导入到数据恢复平安环境中，再由服务器管理员亲自验证数据库的完整性，通过验证所有数据均残缺没有缺失、数据库挂载胜利、下层利用运行失常，本次虚拟机数据恢复实现。

服务器数据恢复环境： 某品牌服务器riad5，存储的是一般类型文件。 服务器故障： 在失常工作状态下服务器意外断电，服务器管理员重启服务器发现该服务器内的raid信息失落，服务器无奈应用。 服务器故障剖析： 本次服务器数据恢复案例的故障是典型的因为意外断电导致服务器raid模块损坏，raid信息失落是raid模块损坏的一种状况。 服务器数据恢复过程： 1、对呈现故障的服务器内所有硬盘进行物理检测，该服务器内所有硬盘读取失常，没有发现物理故障，不须要进行硬件修复。 2、服务器数据恢复工程师对服务器的数据进行镜像备份，前期的数据恢复工作只对镜像数据进行操作。 3、北亚服务器数据恢复工程师对镜像数据进行raid构造剖析，获取该服务器的raid阵列硬盘排列程序、阵列校验形式、硬盘数据块大小等用于重组阵列的必要数据，而后通过这些数据重建raid阵列。 4、对新建的raid阵列进行逻辑校验，逻辑校验顺利通过，所有参数正确无误。 5、服务器管理员亲自对复原进去的数据进行验证，通过验证确定复原进去的数据残缺无误。数据恢复工程师将复原进去的数据迁徙到筹备好的新服务器内，服务器失常启动运行失常，本次数据恢复实现。

在服务器运行过程中不免呈现故障导致数据的失落，哪些服务器故障会导致数据失落呢？ 1、同一阵列内多块硬盘呈现故障；2、服务器模块老化；3、服务器零碎更新；4、意外断电；5、谬误的拔插服务器硬盘；6、误删除等人为因素。 一旦服务器呈现故障导致数据失落，服务器管理员要做的第一件事就是将故障服务器内所有运行失常的非热备盘进行镜像备份，将呈现故障的硬盘进行爱护，防止磕碰、进水等。如果条件容许的状况下能够借助业余数据恢复工具将故障硬盘里的数据也进行镜像备份。获取到镜像数据后对数据进行剖析，找出原阵列的构造参数，重建服务器阵列及逻辑校验都必须这些参数，通过校验后即可胜利导出服务器数据。 如果服务器因为未知起因呈现解体、无奈启动等问题须要对硬盘进行收盘解决的时候，切忌非专业人士在非干净空间内对服务器内的硬盘进行装配、更换电机、更换磁头等操作。倡议服务器管理员将故障硬盘进行妥善保存分割业余正规的数据恢复机构进行解决。 上面就是一个服务器多块硬盘离线导致服务器解体的数据恢复案例： 服务器数据恢复环境： 服务器故障：因为硬盘故障导致服务器解体，在当地一家数据恢复公司进行了数据恢复，然而没有胜利复原进去数据，于是服务器管理员分割到咱们数据恢复核心进行数据恢复。 服务器数据恢复过程：1、该服务器管理员将服务器内的所有硬盘送到咱们数据恢复核心，数据恢复核心的硬件工程师首先对所有硬盘进行物理检测，经检测未发现硬盘物理故障，也就是说该服务器解体并不是硬盘物理故障造成的。2、服务器数据恢复工程师对硬盘进行了全盘镜像，剖析镜像文件尝试找出服务器故障起因。3、通过剖析发现服务器内至多有2块硬盘离线而导致服务器解体，北亚数据恢复工程师应用穷举法将最早掉线的硬盘剔除后重组磁盘阵列。4、将生成的数据和服务器内的另一组完整raid同时挂载到原服务器上进行校验，通过服务器管理员亲自验证，该服务器内的所有数据胜利复原。

服务器数据恢复环境：IBM某型号存储服务器；16块单盘容量600G的FC硬盘。 服务器故障：指向10号和13号硬盘的指示灯显示为黄色；存储映射到redhat上的卷挂载不上，业务中断。 存储服务器数据恢复过程：1、通过IBM storage manager连贯到服务器上查看以后存储状态：服务器报告逻辑卷状态失败，6号盘报告“正告”，10号和13号盘报告“失败”。2、通过IBM storage manager将以后存储的残缺日志状态备份下来，解析备份进去的存储日志获取对于逻辑卷构造的局部信息。3、服务器数据恢复工程师将16块FC盘做好标记，依照原始槽位号注销后把这16块FC硬盘从存储中取出。应用数据恢复应用的FC盘镜像设施对16块FC盘进行粗略测试，均能失常辨认；对16块盘的SMART状态进行检测，6号盘的SMART状态为“正告”，和在IBM storage manager中报告统一。4、数据恢复工程师在windows环境下将设施辨认进去的FC盘在磁盘管理器中标记为脱机状态，对原始磁盘写爱护。而后对原始磁盘进行扇区级别镜像备份，将原始磁盘中的所有物理扇区镜像到windows零碎下的逻辑磁盘并以文件模式保留。镜像过程中6号磁盘的镜像速度不失常，联合之前6号磁盘的SMART状态，能够判断6号盘存在损坏和不稳固扇区。5、应用坏道硬盘专用镜像设施对6号硬盘进行备份，发现6号盘的坏道不多，然而存在大量读取响应工夫长的不稳固扇区。调整拷贝策略对6号盘进行镜像备份。6、实现所有磁盘镜像后，对生成的日志进行剖析，发现在IBM storage manager和硬盘SMART状态中均没有报错的1号盘存在坏道，10号和13号盘均存在大量不法则的坏道散布。依据坏道列表定位到指标镜像文件，发现ext3文件系统的局部要害源数据信息因为坏道曾经被毁坏，只能期待6号盘镜像结束后，通过同一条带进行xor以及依据文件系统上下文关系手动修复损坏的文件系统。7、尽管坏道镜像设施对6号盘的镜像实现，然而先前的拷贝策略会主动跳过一些不稳固扇区，所以做进去的镜像是不残缺的，调整拷贝策略，持续镜像被跳过的扇区，实现6号盘所有扇区的镜像。8、实现所有硬盘镜像后，依据对ext3文件系统的逆向以及日志文件的剖析，获取到16块FC盘在存储中的盘序，RAID的块大小，RAID的校验走向和形式等信息。利用获取到的信息虚构重组RAID，实现RAID搭建后进一步解析ext3文件系统，通过和服务器管理员沟通提取出了一些oracle的dmp文件，尝试利用dmp文件进行数据恢复。9、在利用dmp文件进行数据恢复的过程中，oracle报告imp-0008谬误。北亚的oracle工程师通过剖析导入dmp文件的日志文件，发现复原进去的dmp文件存在问题。10、从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。通过数小时的致力，从新复原进去dmp文件和dbf原始库文件，将复原进去的dmp文件进行数据导入测试，没有呈现问题，证实了这次复原进去的数据是没有问题的。11、对复原进去的dbf原始库文件进行校验检测，所有文件均能通过测试。12、和服务器管理员进行沟通后，最终决定应用复原进去的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.comORA-01110: data file 1: '/oradata/syntong/system01.dbf'ORA-01207: file is more recent than control file - old control file通过进一步的检测和剖析，判断此故障为管制文件和数据文件信息不统一，这是一类因断电或忽然关机等引起的常见故障。3、对数据库文件一一检测，检测到所有数据文件没有物理损坏。4、在mount状态下对管制文件进行备份，alter database backup controlfile to trace as ' /backup/controlfile'。对备份的管制文件进行查看批改，获得其中的重建管制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。5、敞开数据库，删除/oradata/syntong/下的3个管制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。SQL>startup nomount/frombyte.comSQL>@controlfile.sql6、重建管制文件实现后，启动数据库报错，须要进一步解决。SQL> alter database open;alter database open/frombyte.com*ERROR at line 1:ORA-01113: file 1 needs media recoveryORA-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 0Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log…做介质复原，直到返回报告，复原实现。7、尝试open数据库。SQL> alter database open resetlogs;8、数据库启动胜利。把原来temp表空间的数据文件退出到对应的temp表空间中。9、对数据库进行各种惯例查看，没有任何谬误。10、进行emp备份。全库备份实现，没有报错。将应用程序连贯到数据库，进行利用层面的数据验证。 ...

服务器故障： 服务器内两块硬盘掉线，lun失落。 服务器故障检测剖析： 硬件工程师对故障服务器进行检测发现掉线的硬盘没有坏道和其余物理故障，对故障服务器所有硬盘进行镜像备份。 须要进行数据恢复的故障服务器硬盘无物理故障，能够判断硬盘掉线的起因是硬盘读写不稳固，被控制器默认将读写不稳固的硬盘当作坏盘踢出，掉线硬盘数超过了2个后就会导致服务器不可用，此时通过惯例形式是无奈进行数据恢复的。 通过剖析该服务器内的raid条目存储模式，获知每个硬盘的不同块组成一个raid条目，服务器数据恢复工程师解析进去raid条目信息后发现每个LUN都有一份LUN_MAP。EVA将LUN_MAP别离寄存在不同的磁盘中，应用一个索引来指定其地位。找出每个磁盘中指向LUN_MAP的索引就能够找到现存LUN的信息了。 服务器数据恢复过程： 1、通过剖析确定硬盘是因为性能起因掉线，掉线硬盘中一部分数据是老旧数据。因为LUN的阵列大多是RAID5，只须要将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值作比拟就能够判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就能够晓得这个LUN中哪些RAID条目中有掉线盘。而这些RAID条目中都存在的那个盘就肯定是掉线盘。 2、排除掉线盘，而后依据LUN_MAP复原所有LUN的数据。 3、上述的故障剖析以及解决方案须要编写程序实现。北亚数据恢复工程师编写扫描LUN_MAP的程序扫描全副LUN_MAP，联合人工剖析获取最准确的LUN_MAP。 4、数据恢复工程师编写检测RAID条目标程序检测所有LUN中掉线的磁盘，联合人工剖析排除掉线的磁盘。 5、数据恢复工程师编写LUN数据恢复程序，联合LUN_MAP复原所有LUN数据。 6、依据性能需要去编写不同的程序，最初应用LUN数据恢复程序联合LUN_MAP复原所有LUN的数据。而后人工核查每个LUN，确认复原进去的数据是否和服务器管理员提出的需要统一。 服务器复原数据验证： 从服务器管理员那里获知：所有LUN的数据分两块：一部分是Vmware虚拟机，一部分是HP-UX上的裸设施。裸设施里寄存Oracle的dbf数据库。因为复原进去的数据是LUN，无奈看到外面的文件，因而须要将这些LUN通过人工来核查哪些LUN是寄存Vmware的数据，哪些是HP-UX的裸设施里的Oracle的dbf数据库数据。而后将LUN挂载到不同的验证环境中来验证复原进去的数据是否残缺。 1、在一台服务器上安装ESXI虚拟环境，通过iSCSI的形式将复原进去的LUN挂载到虚拟主机上。因为ESXI版本的起因无奈间接扫描到vmfs卷。于是将所有合乎vmware虚拟机的LUN外面的虚拟机文件都生成进去，而后通过NFS共享的形式挂载到虚拟主机上，而后将虚拟机一个一个的增加到清单。 2、验证vmfs虚拟机。通过NFS将所有虚拟机都增加到虚拟主机当前将所有虚拟机开机，所有虚拟机都能失常启动零碎。由服务器管理员输出明码进入每个虚拟机的操作系统，验证虚拟机外面的数据，确认复原进去的数据没问题。至此，本案例数据恢复胜利。

服务器数据恢复环境：某品牌服务器存储+多台存储阵列柜；硬盘近100块；近20组lun。 服务器故障状况：机房漏水导致服务器中的8块硬盘同时掉线，服务器解体。服务器管理员分割数据恢复核心返回现场进行数据救济。 服务器故障检测：数据恢复核心安顿2名服务器数据恢复工程师和1名服务器硬件工程师返回现场进行服务器故障检测，数据恢复工程师达到现场后发现机房内一组存储机柜未开机，通过和服务器管理员沟通得悉：因为机房天花板渗水导致这台机柜下层的两台服务器呈现故障，其中一台通过检修后失常工作，但另外一台服务器则齐全受损。服务器数据恢复工程师对故障服务器进行检测，故障状况如下： 这台被齐全损坏的服务器内一共有多组mdisk退出到了一个池中，而这个池当初曾经不能通过失常路径加载，具体的故障状况能够看下图： 服务器数据恢复过程：1、对服务器做过认真检测后，服务器硬件工程师对掉线硬盘进行物理故障检测，对存在物理故障的进水磁盘在无尘环境中收盘，对盘腔进行清洁、干燥、修复等操作，使进水的故障硬盘复原到能够在数据恢复设施上可读的状态，并对其进行镜像备份。2、对服务器内没有物理故障的硬盘进行镜像备份，将所有数据镜像到数据恢复专用存储池中。3、通过服务器数据恢复工程师对镜像文件进行剖析，获取到了原服务器阵列的存储形式、块大小，条带大小等根底信息。利用获取到的阵列信息在北亚数据恢复专用存储池中重组阵列，而后将镜像数据恢复到虚构阵列中，由管理员对重组后的数据进行验证。4、通过机房管理员对重组后的阵列进行亲自验证，确认所有复原进去的数据残缺可用，认可本次数据恢复后果。5、从新搭建机房服务器环境，数据恢复工程师将数据迁徙回机房的服务器上，本次数据恢复实现。

服务器数据恢复环境：web服务器；8块容量500G的硬盘组成raid6磁盘阵列；存储数据：数据库+办公文件。 服务器故障状况：raid6阵列中有两块硬盘离线，然而服务器管理员没有为服务器更换硬盘，等到阵列中第三个硬盘离线，服务器解体。服务器管理员分割一家数据恢复公司对服务器进行数据恢复，尽管复原了局部数据，然而数据库因为局部数据损坏无奈应用，还有数十天的办公文件不见了。于是该数据恢复公司举荐了咱们数据恢复核心，服务器管理员带着服务器来到咱们数据恢复核心进行二次数据恢复。 服务器数据恢复过程：1、通过和服务器管理员进行沟通，服务器数据恢复工程师这台服务器的故障状况。将所有服务器硬盘镜像到数据恢复存储池中。2、对服务器的镜像文件进行剖析，数据恢复工程师发现阵列内最早离线的两块硬盘离线至多有2个月，所以数据恢复的要害就是最初一块离线的硬盘。3、该服务器的raid6阵列应用的是双校验，因为有两块硬盘长时间处于离线状态，曾经无奈应用一般的异或运算对服务器进行数据恢复。只能应用基于Reed-Solomon算法生成的第二种校验形式进行数据恢复，这种数据恢复办法目前是北亚数据恢复核心的外围算法之一。4、数据恢复工程师们编写了一个通用的小程序将被毁坏的数据进行了重组和提取，而后生成为残缺镜像，在数据恢复核心平安存储池内对复原出的数据进行验证，确认没有问题后分割服务器管理员亲自对数据进行验证。经服务器管理员亲自验证，确认该服务器内所有数据全副复原，数据库能够失常应用，本次服务器数据恢复胜利。

服务器数据恢复环境：某品牌服务器；ESXi6.5虚拟化零碎，调配多个lun；其中一个lun上有8台虚拟机。 故障：服务器管理员在保护时误删除了8台虚拟机中的1台，这台被误删除的虚拟机上存储了SqlServer2000数据库和其余数据，服务器管理员分割数据恢复核心要求复原该虚拟机。 服务器数据恢复故障剖析：这个案例波及了ESXi文件系统，北亚数据恢复核心多年以前开始对vmfs文件系统进行构造钻研，把握了底层数据存储构造，有能力对ESXi虚拟化零碎进行数据恢复。在本案例中，服务器管理员误删除了服务器数据后马上向领导报告状况并申请敞开了服务器、爱护了原始数据，而后分割咱们进行上门复原数据。通过数据恢复工程师检测，确认服务器底层数据未被毁坏，数据恢复的成功率很高。 服务器数据恢复过程：1、服务器数据恢复工程师对服务器硬盘做镜像备份。2、对镜像文件进行剖析，获取故障服务器上的原虚拟机虚构磁盘大小、操作系统类型、虚构磁盘模式、调配状态等信息。3、应用数据恢复核心自主研发的frombyte recovery for ESXi工具对虚构磁盘进行扫描，发现有两个虚构磁盘的状态被标记为“NO”，服务器数据恢复工程师判断这两个虚构磁盘可能本来就属于服务器管理员删除掉的虚拟机。4、数据恢复工程师将这两个虚构磁盘进行复原。5、服务器的虚构磁盘复原实现后，数据恢复工程师将复原进去的数据导入到本地服务器上，挂载到虚拟机上能够失常启动。6、通过服务器管理员亲自验证，复原进去的数据残缺可用，本次服务器数据恢复胜利。

服务器数据恢复环境：华为OceanStor系列服务器；24块硬盘组成一组raid5盘阵，其中一块硬盘为热备盘。 服务器故障状况：服务器运行过程中有一块硬盘离线，热备盘激活上线进行数据同步，在数据同步的过程中服务器内另一块硬盘因未知故障离线，服务器下层利用解体，服务器数据失落。服务器管理员分割数据恢复核心寻求帮忙。 服务器数据恢复过程：1、数据恢复核心接到该故障服务器所有硬盘后马上对每块硬盘进行硬件故障检测，最终发现只有一块硬盘存在物理故障。服务器数据恢复工程师对所有硬盘做了镜像备份。2、剖析服务器故障起因。因为华为s系列服务器的控制器查看磁盘的策略相当严格，对于无物理故障但性能不稳固的硬盘会当作坏盘解决，踢出raid阵列。通过物理故障检测发现只有一块硬盘存在物理故障，因而该服务器掉线的两块盘中另外一块硬盘掉线是因为读写不稳固被踢出。3、剖析服务器raid构造。复原lun首先须要剖析底层的raid构造信息，依据剖析获取的raid信息重组raid。服务器数据恢复工程师对每一块硬盘进行剖析，获取到raid阵列的条带大小、数据走向、硬盘程序、热备盘、数据库的散布法则等根底信息。4、通过校验排查服务器内被同步硬盘。依据曾经获取到的服务器阵列信息，数据恢复工程师应用自主研发的raid虚构程序进行raid重组。数据恢复工程师将所有硬盘进行底层数据结构比照，发现了其中一块硬盘在雷同条带上的数据与其余硬盘显著不同，应用北亚自主研发的raid校验程序对该硬盘进行条带校验后确认该硬盘已被同步毁坏。服务器数据恢复工程师重组raid阵列后剖析lun在raid组中的分配情况及数据块map，只有可能残缺的将map提取就可复原lun数据。5、提取服务器内数据库文件并修复数据库。服务器数据恢复工程师自主编写了文件系统解析程序对虚构阵列内的文件系统进行解析，导出数据库文件后移交数据库工程师进行校验和修复。数据库工程师对数据库文件进行验证发现局部数据库文件及日志文件异样。表空间内存在大量坏块，所有管制文件被毁坏，undotbs02失落，数据库工程师只好对数据库文件进行修复，修复过程见下图： 服务器数据恢复验证：通过数据库工程师对数据的修复和验证，最终胜利复原数据库数据，工程师将修复胜利的数据库数据导入数据恢复专用服务器进行验证，所有数据失常，分割用户亲自进行现场数据验证，确认复原进去的数据没有问题。

服务器数据恢复环境：一组raid5磁盘阵列作为共享存储池，存储数据库和其余一般文件。 故障：服务器运行过程中硬盘掉线导致服务器D分区无奈辨认，服务器管理员对服务器进行重启，服务器掉线硬盘从新上线并同步数据，同步到36%时服务器被管理员强制关机导致数据失落。服务器管理员分割数据恢复核心进行数据恢复。 服务器数据恢复检测：数据恢复工程师达到现场后对服务器进行检测。首先对服务器硬盘进行物理检测排除物理故障。最终确定硬盘离线是因为读写不稳固造成的。随后数据恢复工程师对服务器内所有硬盘进行扇区级别的镜像备份。 服务器数据恢复过程：1、北亚数据恢复工程师对镜像文件进行剖析，获取原服务器raid5条带大小、盘序等要害信息。2、通过和服务器管理员沟通，具体理解了原服务器阵列的配置信息。3、将服务器内所有硬盘依照mdisk组进行分类，剖析mdisk组获取到所有硬盘的阵列组信息，重组raid阵列，提取阵列数据。4、通过上述服务器数据恢复操作后，胜利提取出原服务器内的数据，对提取进去的数据进行校验发现局部数据库文件损坏。5、从新调整数据恢复工具参数，扫描原服务器内的数据碎片并提取。6、对提取进去的dat碎片进行剖析并重组拼接，验证dat数据完整性，验证发现底层构造有损坏。7、持续对分区自由空间进行扫描，拼合自在空间数据碎片，从新生成数据库文件并验证，教训证数据库能够失常加载，下层利用能够失常应用。 数据恢复工程师对重组后的数据进行验证未发现异常，分割服务器管理员对数据恢复后果进行验证，确认原服务器内的所有数据均复原胜利。

服务器数据恢复环境：Windows Server服务器；零碎中装置了Hyper-V虚拟机环境；虚拟机文件寄存在一台DELL PowerVault系列存储中；PowerVault系列存储配置：4个600G硬盘组成阵列寄存虚拟机数据，1个4T硬盘用作虚拟机数据备份。 故障：因为PowerVault系列存储中虚拟机数据文件失落，导致Hyper-V服务瘫痪，虚拟机无奈应用。服务器管理员分割北亚数据恢复核心进行数据恢复。 故障状况检查和剖析：1、工程师达到现场后对存储服务器进行物理检测，发现存储不存在物理故障，硬盘都是失常的。对操作系统进行查看也未发现错误过程，排除因操作系统问题导致的数据失落。2、剖析失落数据硬盘的文件系统，文件均可失常关上，杀毒软件也没有查出异样，排除病毒破坏。然而，数据恢复工程师发现此文件系统的元文件创建工夫为11月28日，意味着文件系统的创立工夫和数据失落的工夫雷同；这意味着文件系统被人为重写，即分区被格式化了。3、查看系统日志发现11月28号之前及当天的系统日志已被清空，审核日志和服务日志却还在。通常状况下，格式化分区的操作只记录在系统日志中，这也验证了存在人为毁坏。4、尝试复原系统日志，然而通过仔细分析硬盘的底层数据，发现硬盘底层中须要复原的系统日志已被新的日志记录笼罩，无奈复原。5、剖析操作系统中的所有分区发现只有存储中两个分区被从新写入文件系统了。通常状况下，对两个分区的格式化须要两个独立的操作，从侧面验证这是人为导致的数据失落。 服务器数据恢复过程：1、备份数据。数据全副都放在这台PowerVault系列存储中。将存储中所有的硬盘编号，而后取出交给硬件工程师检测硬盘是否存在物理故障。如果硬盘失常则对硬盘做全盘镜像。如下图：备份所有硬盘数据 2、重组磁盘阵列。剖析每块硬盘上的数据发现4块600G硬盘做了一个RAID5，另一块4T硬盘是作为数据备份。仔细分析4块600G硬盘中的数据结构，能够获取此RAID的相干信息，利用获取到的raid信息重组raid。如下图：重组RAID 如下图：关上硬盘阵列的状况 3、扫描旧的文件索引项。剖析硬盘底层数据发现许多以前文件系统的目录项及文件索引的残留碎片。通过核查发现这些文件索引指向的数据都是用户失落的文件内容。数据恢复工程师编写提取文件索引项的程序对整个硬盘中所有存在的文件索引项做扫描，提取所有文件的文件索引项。 4、剖析扫描到文件索引项。对扫描到的所有文件索引项进行剖析发现这些索引项是不间断的，大多都是以16K或8K对齐的。失常状况下文件索引项是间断的，大小为固定的1K，每个文件索引项对应一个文件或目录。而扫描进去的这些不间断且不残缺的文件索引项是无奈失常索引到文件的内容。因而须要对扫描进去的文件索引项做加工解决，直到找到所有的文件索引项。 如下图：是文件索引项截图 5、将文件索引项拼接成残缺的目录构造。找到所有的文件索引项后依据文件索引项的编号将其拼接成整个目录项构造。以下是搜寻到的局部文件索引项，因为有局部文件索引项被毁坏，因而只能找到大部分文件索引项，但这些文件索引项曾经足以拼接成整个目录构造了。如下图：是扫描到的文件索引项碎片 6、修复文件系统。将拼接好的目录构造和现有文件系统中的目录构造进行替换，而后应用业余工具批改局部校验值。再应用业余的工具解释这个目录构造就能够看到失落的数据了。如下图：是用业余工具解释进去的目录构造 为了确定数据是否正确，将其中一个最新的VHD文件复原进去并将其拷贝到一台反对附加VHD的服务器上，尝试附加此VHD，后果附加胜利。查看VHD中最新的数据是否残缺。如下图：复原进去的虚拟机数据文件 7、验证数据。在一台测试服务器上搭建Hyper-V的环境，将复原进去的虚拟机文件连贯到这台服务器上。而后通过导入虚拟机的形式，将复原进去的数据都迁徙到新的Hyper-V环境中。而后验证所有虚拟机是否残缺。如下图：虚拟机导入过程 8、迁徙所有数据。服务器管理员验证所有虚拟机后确认没问题，将所有数据拷贝到原服务器中。而后利用导入的形式将虚拟机导入到原服务器的Hyper-V环境中，导入后没有报错，所有虚拟机启动胜利。

服务器数据恢复环境：HP服务器挂接一台由5块1TB硬盘组成的RAID5磁盘阵列（应用的HP SMART ARRAY）。 故障：服务器失常运行过程中一块硬盘掉线，因为RAID5的特点，数据没有出问题。服务器持续运行不久后就呈现故障，服务器保护人员将剩下的4块硬盘重新组建了RAID5并实现数据同步，原来数据全副失落。服务器管理员分割北亚数据恢复核心进行数据恢复。 服务器故障剖析：HP SMART ARRAY在创立一组新的RAID5时，默认会全盘重建所有块校验，在组成RAID5的任一条带中，总有一个校验块的数据是创立时生成的。通过剖析，后生成的4块盘组成的新RAID5是按双循环，64K块大小，16次条带换校验的形式组织的，即在4块磁盘中，大概每隔3M便会有1M的数据是谬误的。通过剖析得悉，原先的5块盘组成的RAID5的构造为双循环、128K块大小、16次条带换校验。要想复原数据，必须修复早掉线的硬盘。解决思路是，通过对前后两次组成构造的差异性剖析，用之前掉线的盘从新补回重建RAID时毁坏掉的校验信息，再虚构重组RAID，解释文件系统，导出文件。 服务器数据恢复过程：1、备份源介质。2、依据毁坏前后的数据痕迹，获取毁坏前后的RAID构造。3、北亚数据恢复工程师剖析前后2个raid5的差别，编写校验修改程序，同时按之前的RAID构造虚构重组，生成重组后的镜像文件。4、北亚数据恢复工程师修改重组后的镜像文件零碎谬误。5、局部分区导出数据，局部分区在无错的前提下齐全镜像到新空间。6、测试、验收。 服务器数据恢复后果：历时24小时数据恢复实现，服务器管理员亲自对复原数据进行验证，确定数据残缺可用。

服务器数据恢复环境：两组别离由4块硬盘组成的raid5；两组raid5都划分为lun，组成lvm构造；ext3文件系统。 故障：raid5中一块硬盘故障离线，热备盘上线开始同步数据，数据同步尚未实现的时候另一块硬盘未知起因掉线，热备盘同步失败，这组raid5解体无奈应用，lvm构造损坏，文件系统也无奈失常应用。北亚数据恢复工程师对两块故障硬盘进行了检测，确认第一块离线硬盘存在物理故障，必须进行物理修复，后掉线的硬盘能够失常辨认。 服务器数据恢复计划：北亚服务器数据恢复工程师依据故障状况制订针对此raid5阵列的数据恢复计划：1、由北亚硬件数据恢复工程师对存在物理故障的硬盘进行物理修复，而后借助业余的数据修复工具“MRT”将物理修复后的故障硬盘进行备份，提取硬盘内的原始数据。2、对于同一组raid阵列中的能够辨认的硬盘则应用工具进行扇区级镜像备份。3、将镜像进去的所有硬盘数据进行剖析，依据获取到的raid信息重组raid5阵列。4、对重组出的磁盘阵列进行剖析，找到失落的lvm信息，重组lvm卷。5、再对raid5阵列上的lvm卷进行剖析，解析出ext3文件系统数据，复原并导出。 服务器数据恢复过程：1、故障盘修复。北亚硬件工程师对故障盘进行收盘操作发现这块硬盘被关上后发现盘片重大磨损，存在大量显著划痕，无奈修复，下面的数据无奈读取进去，后续的数据恢复操作只能进行缺盘解决。2、raid5硬盘镜像备份。因为故障硬盘曾经不可复原，只能持续应用数据恢复工具对能够辨认的硬盘进行镜像备份，同时对原服务器上的另一组失常raid5上所有硬盘进行镜像备份。3、重组raid5阵列。北亚数据恢复工程师对备份镜像上的底层数据进行了剖析，联合已知的EXT3文件系统构造剖析获取raid5阵列的盘序、条带、校验方向等重组阵列的必须信息，而后借助数据恢复工具将raid5进行了重组，对于无奈修复的故障硬盘进行缺盘解决。4、重组LVM构造。北亚数据恢复工程师重组raid5后，剖析raid阵列的底层数据，找到与数据恢复必须的lvm构造信息，剖析lvm构造并提取出raid阵列中的lvm物理卷lun，重组pv，生成lvm逻辑卷。5、复原raid5数据。依照下面制订的数据恢复计划，重组lvm当前，北亚数据恢复工程师剖析逻辑卷内的EXT3文件系统并导出所有数据。 服务器数据恢复后果：在本次数据恢复案例中，因为其中一块硬盘重大划伤，无奈修复，无奈复原下面的数据。在数据恢复过程中会呈现raid构造缺点或者局部文件损坏的状况，所幸本数据恢复案例中的大部分文件都胜利复原并通过了验证，只有3%的数据损坏无奈复原。通过服务器管理员亲自验证，认可本次数据恢复后果。

服务器数据恢复环境：文件系统是reiserfs的服务器；4块146G SAS硬盘组成的RAID5；分区构造：一个几十M的boot分区，一个271G的LVM卷，一个2G的swap分区，LVM卷中间接划分了一个reiserfs文件系统作为根分区。 故障：服务器在运行过程中因为未知起因零碎瘫痪，服务器管理员重装系统后发现整个RAID逻辑卷变成了：2G的boot与swap分区，271G的LVM卷，LVM卷中文件系统地位有个空的reiserfs超级块。服务器管理员分割北亚数据恢复核心进行数据恢复。本案例要复原的数据包含271G的LVM卷中文件系统里的所有用户数据，这些数据蕴含了数据库、网站程序与网页、单位OA零碎里的所有办公文档。 服务器数据恢复过程：1、通过对全盘reiserfs树节点之间的关联确定原来的reiserfs分区地位，北亚服务器数据恢复工程师发现原来存储数据的文件系统的前2G数据曾经被笼罩，应该是服务器管理员在装置零碎时谬误地初始化了分区构造，装好零碎后无奈导入LVM卷，而后应用reiserfsck试图修复文件系统。 注：因reiserfs文件系统对文件系统里所有的文件(含目录)线性化后，以文件key生成B+树，树一直减少节点，树的构造整体拉展后会向整个磁盘的数据区做平滑迁徙，所以顶级节点通常不会放在文件系统的最后面。通常状况下，根目录的文件KEY号是最小的，所以，文件系统的前2G数据中最多的应该是从根起始门路最近的key节点，而用户数据目录档次较深，节点存在的可能性很高。前2G的数据曾经被笼罩无奈复原，所以文件系统对整个树的索引全失落，再加上reiserfs的树概念设计很形象，重搭建树很艰难。 2、北亚数据恢复核心工程师通过自主开发的程序对原文件系统区域进行key节点扫描并将所有节点导出。而后通过自主开发的程序对所有叶节点从新排序、过滤(去掉之前删除文件抛弃的节点)，从新生成二级、三级、四级等叶节点。抉择分区后面2G空间(这部分数据没有用途了)作为新树的构造区，并生成对应地址信息。 3、目录命名问题的解决方案：如遇到原树门路某节点失落的状况，对其用自定义的key节点编号命名；如无奈确定其父目录，暂退出到/otherfiles下。生成树索引信息，写入特定地位，再依据这些信息，生成超级块，设置clear标记。在suse虚拟机下创立快照，挂载修复好的卷，曾经能够看到文件了。注：虚拟机与快照的目标为了操作可回溯，同时因bitmap等元数据不影响数据，未做修改，故挂载前不可做reiserfsck。 4、在修复用的suse虚拟机下，挂载用于复制数据的指标硬盘，mkfs后将所有数据cp到指标盘。服务器管理员整顿所需数据，修改局部目录文件地位与名称。对于局部失落的散文件，按大小与文件头标记查找，找到后挪动和重命名。 数据恢复后果：因为树的不直观性加上程序的调试导致本案例的数据恢复工作充斥复杂性和不确定性。所幸的是，通过北亚数据恢复工程师团队的不懈努力，所有的重要数据都被找到。

服务器数据恢复环境：DELL EqualLogic PS系列服务器；虚构ISCSI SAN阵列；16块硬盘组成了raid5磁盘阵列；下层蕴含多个大小不一的卷，存放数据次要是虚拟机文件。 故障：服务器底层硬盘故障导致服务器无奈应用，服务器管理员分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程：1、北亚数据恢复工程师首先对原服务器内所有硬盘进行物理检测，发现两块硬盘存在大量坏道。对无故障硬盘只须要做一般镜像备份，对存在坏道的故障盘应用北亚自主开发的软件进行硬盘数据修复并镜像备份。2、获取服务器日志并进行剖析。通过对存储日志的剖析，北亚数据恢复工程师找到两块硬盘的离线工夫，抉择服务器内离线工夫靠后的那块磁盘作为数据恢复应用。3、北亚数据恢复工程师在北亚数据恢复专用存储设备上对所有硬盘进行虚构还原，重组出原始raid状态，在虚构出的raid阵列中借助位图信息提取阵列中的lun信息。4、北亚数据恢复工程师对底层数据和lun信息等进行剖析，提取到了原服务器上的文件系统数据，使用跨区组合的办法对提取到的数据进行重组和验证。 服务器数据恢复后果：北亚数据恢复工程师验证重组进去的数据后未发现异常，于是对所有复原进去的数据进行提取，在北亚数据恢复服务器上搭建与原服务器雷同的虚拟化环境，验证虚拟机文件。最初由服务器管理员亲自验证，确认本次数据恢复后果残缺可用。

服务器数据恢复环境：IBM DS系列存储，一个机头，连贯4个扩大柜；50块600GB硬盘组建的2组RAID；其中一组是由27块600G硬盘组成的RAID5，存放数据是Oracle数据库文件，在存储系统下层一共分了11个卷（10个1TB，1个4TB）。 故障：那组由27块600G硬盘组成的RAID5因为磁盘故障而解体，这组raid5寄存的数据是Oracle数据库文件。服务器管理员分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程：1、北亚硬件工程师对27块硬盘做了硬件检测，发现2块硬盘呈现坏道，SMART的谬误冗余级别超过阀值。服务器数据恢复工程师对25块完整的磁盘做全盘镜像，对2块故障磁盘进行硬件修复并做镜像备份。 2、故障剖析：对这台IBM存储上收集到的日志信息进行剖析，搞清楚2块故障硬盘的掉线先后顺序，从而找到数据最新的那块硬盘，用这块硬盘进行接下来的数据恢复。 3、通过钻研，北亚数据恢复工程师确定了套解决方案：计划一：通过IBM DS存储管理软件进行强制上线，在强制上线之前把存储的所有硬盘都进行备份，之后进行强制上线。计划二：通过对硬盘底层数据分析，进行RAID重组，从底层提取数据，从新加载oracle数据库，调试下层利用。 4、施行第一种解决方案，先在模拟器上进行测试，之后在存储上进行上线操作。通过IBM DS存储管理软件进行强制上线，强制上线之后raid处于降级状态，这个时候设置好热备盘，让热备盘上线进行数据同步，同步完之后下层的卷间接能够用了，所有数据也都可见了，下层利用也能失常应用。第一种解决方案节俭了很多工夫，下层利用也不须要在调试，能够间接启动。 数据恢复后果：因为下层的卷间接可用，数据也都可见了，通过用户亲自验证，数据残缺可用。出于平安思考，还是将卷里的文件都拷贝进去移交给用户。整个复原过程一共历时5天。

服务器数据恢复环境：同友存储；5台以上的虚拟机，其中3台linux虚拟机存储重要数据。 故障：raid解体导致存储无奈启动。 服务器数据恢复流程：1、制订复原计划。与服务器管理员沟通之后，北亚数据恢复工程师查看存储底层数据，剖析存储层次结构，剖析后果如下：存储构造 2、重组raid。重组raid过程中北亚数据恢复工程师发现此存储中的raid5缺失2块盘（第一掉线盘掉线后热备盘顶替，第二块盘掉线导致RAID5处于降级状态，最初第三块盘盘片划伤掉线，最终RAID解体），无奈通过校验间接获取失落盘的数据，所以只能应用和磁盘等同大小的全0镜像进行重组（此办法只可用于紧急情况，因为通过空镜像组成的raid文件系统构造会严重破坏，每个条带都会缺失两个块的数据）。重建raid 3、提取LUN。剖析存储构造，获取存储划分的MAP块。在找到MAP块之后解析获取各个LUN的数据块指针，北亚数据恢复工程师编写数据提取程序提取LUN碎片。提取实现后进行碎片拼接，组成残缺LUN。提取LUN 4、导出LUN内所有虚拟机，尝试启动不胜利，提取虚拟机内文件。导出虚拟机后尝试启动，然而因为操作系统被毁坏虚拟机无奈启动。在虚拟机无奈启动的状况下只能先提取虚拟机内文件，取出文件后进行测试，发现大多数文件都被毁坏，只有局部小文件能够关上。 5、与服务器管理员沟通，剖析前期复原可能性，制订前期复原计划。在与服务器管理员沟通后得悉虚拟机内有mysql数据库，因为数据库底层存储的特殊性，能够通过扫描数据页进行数据提取。在找到此虚拟机后发现虚拟机启用快照，父盘和快照文件都被损坏的状况下惯例合并操作无奈实现，应用北亚自主研发VMFS快照合并程序进行快照合并。 6、获取mysql数据页并剖析。依据mysql数据页特色进行数据页扫描并导出（innodb引擎能够应用此计划，myisam因为没有“数据页”这个概念，所以此办法不可用），剖析零碎表获取各用户表信息，依据各个表的id进行数据页宰割。 7、提取表构造。因为数据库应用工夫已久，表构造也曾多次变更，加上零碎表在存储损坏后有局部数据失落，记录提取过程不顺利。首先获取最后版本数据库各个表的表构造：合并快照前的父盘因为写入较早，应用第一块掉线盘进行校验获取到这个文件的残缺数据，而后提取出其中数据库各个表的表构造，服务器管理员提供了最新版的数据库建表脚本。 8、提取记录。别离应用两组不同表构造对数据记录进行提取，导入到复原环境中的mysql数据库内，而后剔除各个表中因为表构造变更造成的乱码数据，最初将两组数据别离导出为.sql文件。 9、验证数据。因为两个版本的数据库表构造不同，所以分割了客户方的利用工程师进行调试，调试实现后导入平台，平台调试胜利，数据恢复实现。

服务器数据恢复环境：EMC存储；stat硬盘组成raid5，两块热备盘。 故障：2块硬盘呈现故障，只有一块热备盘被激活，raid解体。服务器管理员分割北亚数据恢复核心进行数据恢复。 服务器故障检测：北亚数据恢复工程师返回现场对服务器设施进行了简略排查，确认raid5瘫痪，下层lun无奈失常应用，2块热备盘中的1块曾经启动。数据恢复工程师对掉线硬盘进行物理故障排查，两块硬盘均无物理故障。 服务器数据恢复过程： 1、raid5数据备份。数据恢复工程师将服务器上的所有数据进行镜像备份，将所有硬盘连贯到数据恢复核心的数据恢复专用存储池中，对所有硬盘进行了扇区级镜像备份。 2、剖析该服务器raid组构造。服务器数据恢复通常都是基于还原raid阵列来进行数据恢复的。数据恢复工程师对raid阵列根底信息进行剖析，基于获取到的raid信息重组raid阵列。通过数据恢复工程师对每块硬盘的剖析发现：原服务器内的两块热备盘内全副没有数据，也就是说即便被激活的热备盘也同样没有同步到任何数据，两块热备盘没有起到任何作用。数据恢复工程师只能通过原raid5中的其余硬盘的数据来重组raid5。 3、剖析RAID组掉线盘信息。基于第2步中的数据恢复思路，北亚服务器数据恢复工程师应用自主研发的数据恢复工具解析出这组raid5的根底信息，并虚构重组出了raid5磁盘阵列。在失常服务器数据恢复流程下，数据恢复工程师会将有多块硬盘掉线的阵列中最早掉线的硬盘从阵列中剔除，比对每块硬盘在同一个条带上的数据是否统一，将显著不同的硬盘剔除后进行条带校验，直至找到数据恢复的最佳状态为止。 4、剖析RAID组中的LUN信息。胜利重组出raid5阵列后，北亚数据恢复工程师开始对lun信息进行剖析，而后应用北亚开发的raid数据恢复程序对lun数据的map进行解析和导出。 5、ZFS文件系统解析并修复。应用北亚研发数据恢复工具对下层的文件系统进行解析和复原。本案例故障服务器下层采纳zfs文件系统，对文件系统解析时发现局部文件系统元文件报错，于是北亚工程师对现有的数据恢复工具进行debug调试让程序适应本次数据恢复的理论状况。通过调试发现zfs文件系统解析报错的起因是：故障服务器忽然瘫痪导致文件系统中某些元文件被损坏。北亚数据恢复工程师针对损坏的元文件进行了人工修复，修复实现后zfs文件系统能够被失常解析。 6、导出raid5阵列内所有数据。ZFS文件系统解析实现后，北亚数据恢复工程师最终将raid阵列内的数据残缺导出。由服务器管理员配合搭建数据验证环境，对复原进去的所有数据进行验证。通过验证，原服务器内的所有数据均恢复正常。

服务器数据恢复环境：服务器：SUN光纤存储系统；6枚300G硬盘组成RAID6，划分若干LUN，MAP到不同业务的服务器上；服务器操作系统SUN SOLARIS。 故障：业务新增利用，须要减少一台服务器。服务器管理员在原服务器在线状态下将其中一个lun映射到一台新服务器上。服务器管理员在执行操作之前没有留神到这个刚刚映射过来的卷曾经map到了solaris生产零碎上的某个lun上了。将这个lun映射到新的服务器后，服务器对这个卷开始进行初始化，solaris生产零碎上的磁盘呈现报错，于是服务器管理员重启服务器，重启服务器之后这个卷曾经无奈挂载了。服务器管理员分割SUN原厂工程师进行修复。SUN工程师检测故障状况后执行了fsck操作并胜利挂载文件系统，然而少数数据失落或文件大小为0，而最新的数据全副失落。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。 服务器数据恢复故障剖析：本案例中的故障在san环境下比拟常见，少数状况是服务器管理员在没有具体理解服务器的具体情况而执行操作导致的数据失落。在失常的工作模式下，san调配的卷为独立占用模式，如果服务器管理员将其映射给两个或多个操作系统将会导致文件系统一致性出错。在这种状况下要进行数据恢复，首先要剖析文件系统各个构造的损坏状态。在本次服务器数据恢复案例中，采纳的是UFS文件系统。在UFS文件系统下，复原任何一个文件都要先确认目录信息、节点、数据区是否失常，这3个参数都失常则数据可复原。但执行fsck操作后节点会被革除，即便留下目录信息也无奈与数据一一对应，如果呈现这种状况就只能参考文件外部格局进行类型式的数据恢复了。 服务器数据恢复过程：北亚数据恢复工程师查看硬件之后确认服务器无物理故障。 对呈现故障的lun进行残缺备份，在本次数据恢复案例中无任何硬件故障，失常备份即可。在备份文件中对文件系统进行解析，发现元文件中的iNode的确曾经被革除了，无奈通过还原节点（iNode）复原数据，只能通过文件类型进行数据恢复。数据恢复工程师对用户须要复原的特定文件进行剖析，发现采纳vfs公文零碎的索引文件具备强的类型特色，同时文件中蕴含目录信息。依照公文零碎的索引结构特征，北亚数据恢复工程师编写程序进行数据提取，提取数据后依据特色重新命名。按类型复原数据文件，而后依据索引文件对数据文件进行重新整理。服务器复原数据验证：通过2个工作日的数据分析和复原操作，服务器数据恢复工程师最终提取了原服务器内99%的数据和目录索引文件，通过服务器管理员对复原进去数据进行验证，最终确认所须要的重要数据曾经全副复原。

Mysql数据库数据恢复环境：服务器操作系统windows；mysql5.6单实例，innodb数据库引擎；表内存储数据的是独立表空间；无数据库备份，binlog未开启。 Mysql数据库故障：误操作，应用Delete命令删除数据时未增加where子句进行筛选，导致全表数据被删除，所幸删除数据后未进行任何操作，没有数据笼罩，须要对Mysql数据库误删除的数据进行数据恢复。 Mysql数据库数据恢复计划：1、本数据库数据恢复案例因为未进行备份也未开启binlog，无奈间接复原还原数据库数据，这是数据库数据恢复案例中最常见的。2、对于应用innodb数据库引擎的mysql数据库数据误删除导致记录失落的数据恢复有三种计划：备份还原、binlog还原和记录深度解析。因为本案例中的数据库没有备份，也没有开启binlog，只能应用记录深度解析的计划进行数据恢复。记录深度解析的数据恢复计划原理：模仿innodb引擎记录治理形式，依据表构造信息将二进制文件解析为字符记录。 Mysql数据库数据恢复流程：1、获取数据文件：北亚数据恢复工程师对表构造文件及表数据文件（.ibd）的数据进行剖析和复原。2、应用北亚自主研发的数据库数据恢复工具进行扫描： 在本次数据库数据恢复案例中，用户提供了数据库表构造脚本，能够应用本工具中的5+3性能进行复原。 首先读取表构造信息： 开始解析记录： 本工具默认将记录提取为SQL备份格局，期待解析结束后还原到数据库查看后果： 3、验收数据：数据提取实现后，由服务器管理员亲自对复原进去的数据进行验证，核查复原记录的总数，确认复原的数据残缺可用。

服务器数据恢复环境：ORACLE-SUN-ZFS存储服务器；Windows操作系统；zfs文件系统；4个组，每组8块硬盘；热备盘全副启用。 服务器数据恢复故障：服务器失常运行时突发故障无奈失常工作，服务器管理员重启服务器无奈进入零碎，分割北亚数据恢复核心对服务器内的数据进行数据恢复。北亚数据恢复工程师拿到服务器后，和服务器管理员沟通后，确定服务器故障不是因为断电、进水、异样操作或者其余内部因素造成的。 服务器数据恢复过程：1、服务器故障剖析。在ZFS文件系统中，池被称为ZPOOL。ZPOOL的子设施能够有很多品种，包含块设施、文件、磁盘等，故障服务器中的ZFS文件系统采纳的是三组RAIDZ作为子设施。通过剖析发现，三组RAIDZ内有两组启用热备盘，个数别离为1和3。在启用热备盘后，第一组内呈现一块离线盘，第二组内呈现两块离线盘。以此进行故障现场模仿：三组RAIDZ内第一二组别离呈现离线盘，热备盘及时进行替换；热备盘无冗余状态下第一组呈现一块离线盘，第二组呈现两块离线盘，ZPOOL进入高负荷状态（每次读取数据都须要进行校验失去正确数据）；第二组内呈现第三块离线盘，RAIDZ解体、ZPOOL下线、服务器解体。 2、重组ZPOOL，追踪数据入口。ZFS治理的存储池与惯例存储不同，所有磁盘都由ZFS进行治理。惯例RAID在存储数据时，只依照特定的规定组建池，不关怀文件在子设施上的地位。而ZFS在数据存储时会为每次写入的数据调配适当大小的空间，并计算失去指向子设施的数据指针。这种个性使得RAIDZ缺盘时无奈间接进行校验失去数据，必须将整个ZPOOL作为一个整体进行解析。北亚数据恢复工程师手工截取事务块数据，编写程序获取最大事务号入口：获取文件系统入口 获取到文件系统入口后，北亚数据恢复工程师编写数据指针解析程序进行地址解析：解析数据指针 获取到文件系统入口点在各磁盘散布状况后，北亚数据恢复工程师手工截取并剖析文件系统内部结构。因为入口散布所在的磁盘组无缺失盘，可间接提取信息。依据ZFS文件系统的数据存储构造顺利找到原服务器映射的LUN名称，进而找到其节点。 3、编写数据提取程序并运行。通过仔细分析，北亚数据恢复工程师发现故障服务器中的ZFS版本与开源版本有较大差异，无奈应用北亚数据恢复核心以前开发的解析程序进行解析，所以从新编写了数据提取程序。 因为磁盘组内缺盘个数较多，每个IO流都须要通过校验失去，提取进度极为迟缓。与服务器管理员沟通后得悉ZVOL卷映射到XenServer作为存储设备，所需复原的文件在其中一个大小约为2T的vhd内。北亚数据恢复工程师提取ZVOL卷头部信息，依照XenStore卷存储构造进行剖析，发现2T vhd在整个卷的尾部，计算失去其起始地位后从此地位开始提取数据。 4、验证复原数据。Vhd提取结束后，北亚数据恢复工程师对其外部的压缩包及图片、视频等文件进行验证，文件都能够失常关上应用。分割服务器管理员验证数据，确定文件数量与零碎自动记录的文件个数统一，文件都可失常关上，服务器数据恢复胜利。

服务器数据恢复环境：服务器：Infortrend ESDS系列存储服务器；12块容量2TB的磁盘组成raid6；阵列上一个lun映射到WINDOWS零碎；WINDOWS零碎蕴含一个GPT分区。 故障：服务器运行过程中不可拜访，经查看发现其中有3块硬盘离线，服务器管理员进行强制上线rebuild操作，上线胜利后分区不能关上，数据无法访问。服务器管理员分割北亚数据恢复核心进行数据恢复。Raid6最多容许2块硬盘同时离线，因为用户服务器内3块硬盘先后呈现故障离线，服务器管理员将最先离线的硬盘进行上线操作，则服务器会将所有数据进行算法同步，数据无法访问，服务器解体。 服务器数据恢复过程： 北亚数据恢复工程师对原服务器进行扇区级镜像备份，遇到有物理故障的硬盘先由硬件工程师进行解决后再备份数据。剖析Infortrend存储服务器的RAID6算法，按剖析进去的算法对12块硬盘做C(12，2)共66种可能的缺2盘的状况组合。通过人工或程序断定最正确的缺盘组合。通过北亚自主开发的软件搭建虚构RAID平台，按剖析出的缺盘状态、盘序、块大小、校验方向、RAID6算法构建raid进行附加。先后对搭建进去的虚构RAID进行GPT分区构造解释和文件系统解释，确定算法是否正确。如不正确则调整算法，反复后面的步骤直到获取最佳构造。按文件或扇区形式迁徙数据到另一存储，实现复原工作。通过服务器管理员亲自对复原进去的数据做验证，确认数据正确无效。

服务器数据恢复环境：华为OceanStor系列服务器；MD1200磁盘柜，raid5磁盘阵列组，50T容量；linux操作系统，1个lun；两个分区：分区一通过lvm进行扩容，分区二格式化为xfs文件系统。 故障：用户对服务器重装系统误操作导致原服务器内的第二分区不可拜访，服务器分区内的数据失落，起因不明。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。 服务器数据恢复过程：1、为防止服务器数据恢复操作毁坏服务器的原始数据，北亚数据恢复工程师对原服务器内的所有磁盘进行镜像备份。备份完结后，把原始磁盘重新安装回原服务器内，镜像盘连贯到北亚数据恢复专用设备进行数据恢复。2、北亚数据恢复工程师应用镜像盘剖析raid的盘序、条带大小等信息；3、应用剖析进去的raid相干信息虚构重组出raid构造；4、定位到xfs文件系统的分区起始地位；校验xfs文件系统的完整性及正确性；5、修复xfs文件系统的超级块构造； 修复实现的超级块 6、对xfs文件系统中失落的节点及目录项进行修复； 修复实现的根节点 重做的目录项 7、修复实现后，北亚数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。 数据恢复后果：通过对服务器的xfs文件系统的剖析，北亚数据恢复工程师发现文件系统头部超级块失落，文件系统的局部目录项失落，局部旧节点失落。依据超级块备份及文件系统中的目录树结构，北亚数据恢复工程师对超级块进行修复还原，对失落的节点、目录项进行修补、重构之后，文件系统中的数据能够残缺复原。 修复实现的目录构造 数据安全小贴士：数据失落之后千万不要对存储做任何写入的破坏性操作，防止对数据造成毁坏。

服务器数据恢复环境：IBM DS系列存储，Linux操作系统；8块硬盘组成raid5。 故障：服务器在运行过程中有一块硬盘掉线，热备盘上线并开始主动同步数据，在热备盘上线同步数据过程中，存储中一块其余硬盘因为未知起因掉线，raid同步过程中断，阵列解体，卷无奈挂载。管理员分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程：1、故障检测北亚数据恢复工程师对设施进行了检测，阵列中两块掉线硬盘有物理故障，复原数据之前必须先修复硬件。 2、备份存储数据北亚数据恢复工程师对存储内的所有硬盘进行了镜像备份，将备份盘带回北亚数据恢复核心，在北亚数据恢复专用服务器上进行数据恢复剖析和后续操作。防止损坏原始数据。 3、 剖析存储数据北亚数据恢复工程师对存储进行剖析，获取存储原始raid的raid构造、块大小、raid校验信息等。 4、 重组raid阵列依据剖析失去的原存储raid信息，在北亚数据恢复专用存储设备上虚构重组出一组raid5磁盘阵列，再持续剖析虚构磁盘阵列，从中提取lun信息和失落的数据。 5、 数据验证对提取胜利的数据进行验证，数据验证无误。将验证无误的数据在搭建好的数据验证平台上由服务器管理员亲自验证，所有复原进去的数据残缺可用。 呈现相似的数据失落时，用户应爱护好原始数据的完整性，不要自觉在原存储设备上进行各种操作。如果有肯定数据恢复技术的用户能够对原设施进行只读模式的镜像备份后，再对备份文件进行剖析操作，免得毁坏原始数据。

服务器数据恢复环境：昆腾系列存储；9个配置24块硬盘的磁盘柜；8个存储柜存储数据，1个存储柜存储元数据；元数据存储柜24块146G硬盘：8组RAID1+1组4盘位的RAID10+4个全局热备盘；数据存储柜192块硬盘：32组6盘位的RAID5，分为2个存储系统。 故障：数据存储中的1个存储系统中的一组RAID中的2块硬盘先后故障离线，RAID生效，整个存储系统解体，无奈应用。管理员分割北亚数据恢复核心进行数据恢复。存储及文件系统架构大抵如下： 注：Meta_LUN(元数据卷) Data_LUN（用户数据卷） 数据恢复过程：1、为避免数据恢复过程中因为误操作对原始磁盘造成二次毁坏, 首先对原始存储环境进行备份。对故障RAID中的6块盘进行编号标记，将硬盘从存储柜中插入，接入到北亚数据恢复核心的数据备份服务器上，对6块硬盘进行全盘备份。对其余无故障的RAID进行存储层面的备份。应用光纤线缆将北亚专用数据备份服务器和存储设备连贯，进入昆腾存储设备治理界面进行配置，让备份服务器和存储设备能够失常通信，应用软件对RAID中的LUN进行镜像备份。在备份过程中北亚数据恢复工程师发现故障RAID中的1块故障硬盘存在大量坏道，无奈失常备份。北亚工程师对故障硬盘进行收盘更换固件，并应用PC3000工具进行修复，实现故障硬盘备份。 局部镜像文件 2、数据分析。对故障RAID进行剖析获取到RAID相干信息，北亚数据恢复工程师利用获取到的RAID信息对RAID阵列进行虚构重组，并将RAID中的LUN复原成镜像文件。在剖析过程中发现损坏较重大的硬盘为后离线的硬盘。登录昆腾存储设备的治理界面，获取到StorNext文件系统中卷相干的一些根本信息，如下图： 持续对StorNext文件系统中的Meta卷和Data卷进行剖析。本案例StorNext文件系统中蕴含2个Data卷，每一个残缺的Data卷都是由多组RAID中的LUN组成的，北亚数据恢复工程师对这些LUN进行剖析，失去LUN之间组合的算法法则，虚构重组出残缺的Data卷。 对Meta卷中的节点信息、目录项信息、Meta卷和Data之间的对应关系进行剖析，针对一个Meta卷治理多个Data卷的状况，北亚数据恢复工程师钻研出Meta卷到Data卷的索引算法。 文件节点 目录块 3、通过剖析获取到了数据恢复工作所须要的全副信息，北亚数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息，同时对目录项和节点进行解析，获取残缺的文件系统目录构造，解析每一个节点中的指针信息，将这些信息记录在数据库中。文件信息 4、北亚数据恢复工程师编写文件提取程序读取数据库，依据解析出的信息以及两个Data卷之间的聚合算法对数据进行提取。 验证数据&移交：对生成出的数据进行随机抽样检测，数据没有问题。将全副文件提取到本地，确认提取实现后进行数据移交。

服务器数据恢复环境： emc服务器；raid5磁盘阵列；两块热备盘。 故障： 服务器上有两块硬盘呈现故障，然而热备盘中只有一块被胜利激活，导致了raid阵列瘫痪，服务器的下层利用不可用。管理员分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程： 1、服务器故障检测。首先对两块掉线的硬盘进行物理故障检测，如果发现物理故障，须要对硬盘进行物理修复，而后能力持续下一步数据恢复操作。通过检测，所有硬盘（包含掉线硬盘）不存在物理故障。 2、备份服务器所有硬盘。在数据恢复开始前须要将所有原始硬盘进行镜像备份。服务器硬盘无物理故障可间接备份，因为源磁盘的扇区大小为520字节，因而还须要将所有备份数据做520到512字节的转换。 3、对服务器底层raid组进行数据分析。通过对raid阵列的剖析，北亚数据恢复工程师发现原服务器内的两块热备盘内均为空，没有写入任何数据（由此推断：一块热备盘尽管上线，但此时raid组依然处于缺盘状态，数据并没有开始同步。）。 4、北亚数据恢复工程师顺次剖析整个raid5阵列上的条带大小，磁盘程序等根底信息，开始进行raid重组。 5、依据获取到的RAID信息，应用北亚自主开发的RAID虚构程序将原始的RAID组虚构进去。但因为整个RAID组中一共掉线两块盘，因而须要搞清楚这两块硬盘掉线的程序。 6、仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其余硬盘显著不一样，因而初步判断此硬盘可能是最先掉线的。通过北亚自主开发的RAID校验程序对这个条带做校验，最终确定最先掉线的硬盘。 7、LUN是基于RAID组的。根据上述剖析获取到的信息将RAID组重组进去，而后再剖析LUN在RAID组中的调配信息以及LUN调配的数据块MAP。 8、依据获取到的LUN信息，应用北亚自主开发的raid恢复程序解释LUN的数据MAP并导出LUN的所有数据。 9、解释ZFS文件系统并修复。利用ZFS文件系统解释程序对生成的LUN做文件系统解释，发现程序在解释某些文件系统元文件的时候报错。北亚数据恢复工程师立刻对程序做debug调试，分析程序报错起因，同时剖析ZFS文件系统是否因为版本起因导致程序不反对。通过长达7小时的剖析与调试，最终发现ZFS文件系统因存储瘫痪而导致其中某些元文件损坏，从而导致ZFS文件系统解释程序无奈失常解释。 10、对损坏的文件系统元文件做修复能力失常解析ZFS文件系统。通过对损坏的元文件剖析，北亚数据恢复工程师发现：因当初ZFS文件正在进行IO操作的同时存储瘫痪，导致局部文件系统元文件没有更新或者损坏。北亚数据恢复工程师对这些损坏的元文件进行手工修复，保障ZFS文件系统可能失常解析。 11、对修复后的文件系统进行解析并验证最新数据。通过服务器管理员的亲自验证，确认服务器内所有数据被胜利复原。

服务器故障： 用户误删除了服务器上的卷，raid5磁盘阵列数据失落，分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程： 通过检测，服务器没有物理故障。能够从raid5磁盘阵列层面进行数据恢复。 1、剖析超级快信息，记录raid阵列起始块地位。北亚数据恢复工程师对服务器raid阵列进行数据分析，获取到阵列的逻辑起始块地位号。 2、去除raid阵列的校验盘。通过剖析，这组raid5阵列中每个数据块大小为8扇区，每个数据块后有一个附加的数据块形容信息，大小为64字节，由此在底层找到的0X10地位为FFFF的就是要找的校验块。 3、剖析aggr盘序。因为之前通过剖析曾经获知阵列中的数据块大小为8扇区，所以在进行盘序剖析时也根据每块磁盘的8号扇区进行剖析，确定每块硬盘各自归属的组，再还原硬盘在各自的组内的排序。 4、剖析raid磁盘阵列节点信息。服务器的节点散布在不同的数据块内组成节点组，后面曾经剖析出每64字节记录一些零碎数据，之后用192字节为一项记录各个文件节点。依据用户级别可分为两类：“MBFP”系统文件节点和“MBFI”用户文件节点，在数据恢复时个别只取MBFI节点组即可。 头部信息64字节解析如下：（此头部为数据文件的节点文件块头部，大小为64字节）标记，常量（“MBFP”为元文件的节点标记，“MBFI”为用户文件的节点标记）；依据更新序列值获取到最新节点；解析节点中节点类型，逻辑块号，文件数量，文件大小，所占块数量，及数据指针；获取节点在节点文件中的逻辑块号，从0开始计数。 5、获取目录项，并依据其节点编号，找到对应节点。 6、编写数据提取程序复原服务器数据。依据剖析到的raid阵列信息重组raid5阵列，北亚数据恢复工程师编写数据恢复小程序提取服务器内的数据。 7、搭建服务器环境验证数据。在北亚专用数据恢复服务器上搭建了与原服务器雷同的环境，在下层利用内对数据进行验证，验证无误后由服务器管理员对数据进行最终验证，经管理员验证，本次服务器内的所有数据全副复原，残缺可用。

数据恢复环境：3块硬盘组成raid5磁盘阵列。 故障：组成raid5中的1块硬盘的状态灯呈现红色报警，磁盘阵列呈现故障，服务器分区辨认不了。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。 服务器数据恢复过程：1、北亚数据恢复工程师对服务器硬盘进行初检，发现3块服务器硬盘都能失常辨认，未发现有物理坏道或者其余硬件故障。于是采取惯例的镜像备份办法对服务器所有磁盘进行了只读镜像备份。2、对备份的服务器镜像文件进行底层数据分析，应用winhex剖析出该服务器原raid磁盘阵列内的校验形式、raid盘序、raid构造、raid校验形式等根本信息。北亚数据恢复工程师利用这些信息虚构重组raid5阵列并对重组后的阵列信息进行校验。3、北亚数据恢复工程师对重组后的服务器阵列进行数据验证，并尝试顺次把每一块硬盘离线，而后提取raid数据，后果提取的数据完全一致。4、因为用户服务器分区内有局部数据验证不通过，北亚数据恢复工程师对虚构重组进去的raid阵列内的数据进行从新查看，对服务器dat文件进行修复后再次进行数据验证，发现备份文件仍然有局部损坏。5、持续剖析服务器聚合dat碎片文件，北亚数据恢复工程师发现底层构造仍然损坏。6、持续对服务器分区空间页进行扫描，对文件碎片进行扫描、提取、重组、验证。最终，北亚数据恢复工程师在提取的碎片文件中胜利重组出原服务器raid所有数据并通过验证。7、在北亚数据恢复专用设备上搭建用户的服务器环境，连贯数据库，由用户亲自进行数据验证。经服务器管理员亲自验证，所有复原的数据均可失常加载，下层应用软件失常，本次数据恢复胜利。

故障：因为服务器意外断电，导致服务器上的Oracle数据库报错：“system01.dbf须要更多的复原来放弃一致性”。因为数据库并没有备份，仅有一些断断续续的归档日志，用户分割北亚数据恢复核心修复Oracle数据库。 Oracle数据恢复过程：1、检测服务器及数据库状况。用dbv命令检测数据文件是否是残缺的。见下图： 通过上图能够看到检测的文件数据块中有40页的数据是检测失败的状态。另外有29页的索引数据也是失败状态。除此以外其余文件均为失常状态。 2、挂起并修复数据库北亚数据恢复工程师在北亚数据恢复专用服务器上搭建了一组Windows server环境，并搭建了和原服务器上雷同的Oracle数据库环境，尝试将数据库挂起来，查看Oracle数据库的报错状况，见下图： 3、依据Oracle数据库的报错状况，北亚数据恢复工程师采取了利用在线日志复原数据的办法，应用recover database命令进行oracle数据库修复。4、修复过程中发现，因为归档日志不间断，复原数据库所需时间段的归档日志缺失，北亚数据恢复工程师只能应用cancel参数进行不齐全数据恢复。5、北亚数据恢复工程师再次执行复原命令，关上数据库查问实例状态，发现仍有局部数据报错，报错内容为“ora_00600”，见下图：6、这类数据库外部谬误是无奈通过命令进行修复的，北亚数据恢复核心工程师借助expdp/exp工具尝试对数据库进行导出，但这两个工具导出数据库时仍然有报错，数据库曾经不可能进行修复。 7、解析数据库文件获取数据。应用北亚自主研发的一款dbf解析工具，获取到用户数据库内的数据。见下图：8、北亚数据恢复工程师获取到数据库数据后在北亚数据恢复专用服务器内搭建数据库环境，创立数据库、用户、调配表空间等。将解析进去的数据库数据迁徙到新数据库中。应用toad for oracle工具验证数据。见下图： 9、导出数据库数据并验证。北亚数据恢复工程师再次应用exp工具将数据库导出，导出命令：exp system/abc  file=C:\test\dump\zxfg.dmp log=C:\test\dump\zxfg.log owner=zxfg本次导出失常，没有任何报错。经用户亲自验证，Oracle数据库残缺，本次数据恢复胜利。