数据恢复

<article class=“article fmt article-content”><p><strong>服务器数据恢复案例之服务器raid6中3个磁盘离线导致阵列解体的数据恢复案例</strong><br/>服务器故障：<br/>服务器中有一组由6块盘组建的 RAID6，这台网站服务器上运行MYSQL数据库和寄存其它类型的文件。该组raid中有两块磁盘离线，管理员没有及时更换磁盘，当第3个磁盘离线，raid解体，服务器数据失落。<br/>服务器数据恢复过程：<br/>1、用户方将服务器送到咱们数据恢复核心后，硬件工程师将故障服务器中所有磁盘编号后取出，查看完硬件故障后将这6块磁盘以只读形式残缺镜像到北亚企安数据恢复专用存储池中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。<br/>2、基于镜像文件剖析所有磁盘底层数据，数据恢复工程师发现有两块磁盘离线工夫比拟早，这2块磁盘上没有写入新的数据。此RAID6采纳的双校验，：第一个校验是由一般的XOR运算生成，而第二个校验是由Reed-Solomon算法生成。因为此RAID6较早掉线的两块磁盘早已不写入新数据，所以须要通过第二个校验来复原数据，否则会导致最新数据的失落或损坏。<br/>3、服务器数据恢复工程师通过剖析获取到原始RAID6的相干参数，而后应用北亚企安自主编写的RAID6复原软件生成一个残缺镜像，再将镜像导回用户方新搭建好的环境中，开机一切正常，通过服务器管理员的认真验证，没有发现任何问题，用户方认可数据恢复后果。</p><p><strong>服务器数据恢复案例之服务器RAID5两个磁盘指示灯显示红色导致服务器解体的数据恢复案例</strong><br/>服务器故障：<br/>服务器中有一组应用NetRaid阵列卡+4块磁盘组建的RAID5阵列，下层操作系统为Window2000，运行SQLServer2000数据库。服务器在失常工作时忽然有一块硬盘指示灯显示红色，机器依然在失常运行，一段时间后服务器无奈失常工作，这时候又有一个硬盘指示灯显示红色。管理员将故障服务器送到北亚企安数据恢复核心要求复原其中的数据。<br/>服务器数据恢复过程：<br/>1、数据恢复工程师拿到服务器后将故障服务器通电后开启，服务器启动后自检至阵列时按Ctrl+M进入NetRaid管理程序。查看阵列信息发现有2块硬盘状态为Failed，将其中一块硬盘设置为OnLine，重新启动服务器，硬件自检有效，启动失败。<br/>2、再次启动服务器，自检至阵列时按Ctrl+M进入NetRaid管理程序。抉择磁盘阵列，将原来手工设置为OnLine的硬盘从新设置为Failed，而后再把另一块Failed的硬盘设置成OnLine，重新启动服务器后胜利进入零碎。通过查看发现零碎及数据库运行失常，再次进入NetRaid管理程序将剩下的那块状态为Failed的硬盘手动设置为Rebuild，实现重建后再次重启服务器，胜利进入零碎。通过查看发现阵列和零碎都恢复原状了。通过服务器管理员的亲自验证，没有发现任何问题，用户方认可数据恢复后果。</p><p><strong>服务器数据恢复案例之服务器硬盘呈现坏道/坏扇区离线导致服务器解体的数据恢复案例</strong><br/>服务器故障：<br/>一台有20块硬盘的服务器，在运行过程中上层业务忽然解体，管理员查看后发现服务器解体的起因是服务器上有3块磁盘离线，管理员将服务器内的所有磁盘编号后依照现有盘序从槽位取出送到北亚企安数据恢复核心要求复原服务器中的数据。<br/>服务器数据恢复过程：<br/>1、拿到故障服务器中所有磁盘后，硬件工程师对20块硬盘进行硬件故障检测，通过检测所有硬盘均可辨认，没有发现显著的硬件故障。<br/>2、以只读形式将所有硬盘做扇区级别的残缺镜像，在镜像过程中发现离线的3块磁盘镜像速度异样，联合之前三块磁盘离线，能够判断这三块离线的磁盘应该存在大量的坏道或者不稳固扇区。调整镜像策略跳过硬盘的坏扇区持续做镜像，直到所有磁盘都实现镜像。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。<br/>3、基于镜像文件剖析所有磁盘的底层数据，通过逆向剖析ext3文件系统获取服务器内磁盘盘序和校验信息，利用获取到的raid信息重组raid阵列。<br/>4、和用户方的沟通后，北亚企安数据恢复工程师提取了故障服务器中运行的oracle数据库的dmp文件，而后尝试将dmp文件导入来复原oracle数据库数据，后果数据库报告imp-0008谬误。剖析日志文件后发现提取的dmp文件存在问题，所以导致dmp文件导入失败。<br/>5、从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。通过数小时的剖析后从新提取dmp文件和dbf原始库文件，将提取进去的dmp文件移交给用户方进行数据导入的测试，通过测试没有发现问题。对提取进去的dbf原始库文件进行校验&检测，所有文件均通过测试。<br/>6、用户方对复原数据进行验证后认可数据恢复后果。在服务器上搭建了一组新的raid阵列，在数据恢复工程师的帮忙下将所有数据迁徙到新筹备的环境中。</p></article>

服务器数据恢复环境&故障：10个磁盘柜，每个磁盘柜配24块硬盘。9个磁盘柜用于存储数据，1个磁盘柜用于存储元数据。元数据存储中24块硬盘，组建了9组RAID1阵列+1组RAID10阵列，4个全局热备硬盘。数据存储中，组建了36组6硬RAID5，36组RAID5阵列划分为2个存储系统。其中1个存储系统中的一组RAID5中有2块硬盘先后呈现故障离线，RAID5阵列不可用，存储系统解体。存储及文件系统架构：注：Meta_LUN(元数据卷) Data_LUN（用户数据卷） 服务器数据恢复过程：1、将故障RAID5中的6块盘编号标记后从磁盘柜中取出。通过硬件工程师检测，所有磁盘都能够失常读取。以只读形式对6块硬盘进行扇区级全盘镜像。对磁盘柜中没有呈现故障的RAID阵列进行存储层面的备份。备份示意图：在镜像过程中发现故障RAID5阵列中的1块故障离线硬盘存在大量的坏道区域，无奈持续备份。在用户方的受权下，将故障盘进行收盘更换固件并应用业余工具进行修复，修复实现后该硬盘能够持续备份，但坏道依然存在。局部镜像文件：2、基于镜像文件对故障RAID5阵列所有磁盘中的底层数据进行剖析，获取到重组RAID须要的相干信息，利用获取到的RAID信息虚构重组RAID阵列，并将该RAID阵列中的LUN复原成镜像文件。在剖析过程中发现，存在大量坏道的硬盘为后离线的硬盘。3、登陆昆腾存储的治理界面，读取StorNext文件系统中与卷相干的信息。4、剖析StorNext文件系统中的Meta卷和Data卷。每一个残缺的Data卷都是由多组RAID中的LUN组成的，通过剖析这些LUN获取到LUN之间组合的算法法则，虚构重组出残缺的Data卷。5、剖析Meta卷，剖析Meta卷中的节点信息、目录项信息、Meta卷和Data卷之间的对应关系。针对一个Meta卷治理多个Data卷的状况，钻研Meta卷到Data卷的索引算法。文件节点：目录块：6、通过剖析钻研获取到了复原数据所须要的全副信息，北亚企安数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息，同时通过对目录项和节点解析获取到残缺的文件系统目录构造。解析每一个节点中的指针信息，将这些信息记录在数据库中。文件信息：7、北亚企安数据恢复工程师编写文件提取程序读取数据库，依据解析进去的信息以及两个Data卷之间的聚合算法提取数据。8、对提取进去的数据进行随机抽样检测，没有发现问题。将全副文件提取到本地，由用户方进行检测。通过认真检测后，用户方认可数据恢复后果。本次数据恢复工作实现。

<article class=“article fmt article-content”><p><strong>服务器数据恢复环境：</strong><br/>MD1200磁盘柜中的磁盘通过RAID卡创立了一组RAID5阵列，调配了一个LUN。在Linux操作系统层面对该LUN进行了分区，划分sdc1和sdc2两个分区，通过LVM扩容的形式将sdc1分区退出到了root_lv中；sdc2分区格式化为XFS文件系统。</p><p><strong>服务器故障：</strong><br/>服务器重装系统后，磁盘分区扭转，sdc2分区失落，无法访问。</p><p><strong>服务器数据恢复过程：</strong><br/>1、将故障服务器中所有磁盘编号后取出，通过硬件工程师检测没有发现磁盘存在硬件故障。将所有磁盘以只读形式进行扇区级的全盘镜像，镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。<br/>2、基于镜像文件剖析raid5阵列的盘序、条带大小等raid构造相干信息，利用剖析进去的raid信息虚构重构raid5阵列。<br/>3、定位到xfs文件系统的分区起始地位，校验xfs文件系统的完整性及正确性。北亚企安数据恢复工程师对失落的xfs文件系统的进行检测后发现xfs文件系统头部的超级块及局部节点、目录项失落。<br/>4、依据超级块备份及xfs文件系统中的目录树结构，北亚企安数据恢复工程师对xfs文件系统的超级块构造修复。<br/>修复实现的超级块：<br/><br/>5、对xfs文件系统中失落的节点及目录项进行修复。<br/>修复实现的根节点:<br/><br/>重做的目录项：<br/><br/>6、修复实现后，北亚企安数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。<br/>修复实现的目录构造：<br/><br/>服务器数据恢复总结：发现服务器数据失落之后，用户方没有做任何破坏性的写入操作，所以失落的数据才得以残缺复原。</p></article>

服务器数据恢复环境：dell某型号服务器中有一组通过raid卡组建的raid10，该raid阵列中一共有4块磁盘。下层部署XenServer虚拟化平台，作为网站服务器应用。 服务器故障：服务器异样断电导致服务器上的一台虚拟机不可用。须要复原这台虚拟机上的数据库数据。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，由硬件工程师检测没有发现有磁盘存在显著的物理故障。将所有磁盘以只读形式做扇区级别的全盘镜像。镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件对底层数据进行剖析，通过剖析发现服务器中磁盘通过LVM来治理。进入到“/etc/lvm/backup/”目录下查问是否有损坏的虚构磁盘信息，如果查问有损坏的虚构磁盘信息就阐明LVM信息尚未更新；如果查问没有损坏的虚构磁盘信息就阐明LVM信息曾经被更新，只能通过底层数据查找尚未更新的lvm信息。本案例就是从底层数据中查问到尚未更新的lvm信息。3、找到尚未更新的lvm信息就阐明数据还在，能够基于lvm信息剖析&查找虚构磁盘的分区数据，然而通过数据恢复工程师剖析发现虚构磁盘被毁坏。通过服务器数据恢复工程师的进一步查找和剖析后确认该区域的数据曾经被毁坏，只发现一些数据库页碎片。4、数据恢复工程师试图通过拼接碎片来复原数据。失常状况下rar压缩包的第一个扇区记录文件名，能够依据文件名反向剖析压缩包的数据起始地位，将相应的压缩包底层数据提取进去并重命名。然而本案例中提取进去的压缩包解压时报错。数据恢复工程师尝试应用rar修复工具并设置为疏忽谬误持续解压局部数据，然而依然解压失败。5、在数据库层面剖析数据库的开始地位（数据库第九页是以后数据库名称，通过数据库名称反推数据库的开始地位），剖析出数据库开始地位后，北亚企安数据恢复工程师依据每个数据库页的编号和文件号去底层数据扫描合乎这个数据库页的所有数据，将所有扫描进去的数据重组为一个mdf文件。6、通过校验程序检测重组进去的mdf文件，检测没有问题后提取数据。通过数据恢复工程师们的剖析和重组最终提取出服务器内的所有数据并通过了初步验证。7、数据恢复工程师搭建数据库环境，将复原进去的数据库数据附加进去进行查问，查问后果一切正常，本次服务器数据恢复工作实现。

虚拟机数据恢复环境&故障：由一台物理服务器迁徙到ESXI上的虚拟机，虚拟机迁徙实现后做了一个快照，该ESXI下面一共运行了数十台虚拟机。某天工作人员不小心将快照进行了还原，虚拟机内的数据还原到了数年前刚迁徙过去时的状态，迁徙过去后的这几年更新的数据全副被删除。虚拟机还原快照与删除数据在实质上是一样的，虚拟机删除快照后会将底层存储空间相应的空间开释，而后重用这部分释放出来的空间存储新的数据。所以，如果一台虚拟机不小心还原了快照，应该尽快将还原快照的虚拟机所在存储上的所有虚构机关机或迁徙到其余ESXI上。要复原虚拟机数据，咱们须要先理解vmfs的底层构造，vmfs是wmware自有文件系统，在这个文件系统下所有的硬盘被默认划分为若干个区域，这些区域最小单位被称为“block”，每个block的大小为1MB，每1024个block组成一个MAP，这些信息都记录在文件系统的某一个特定区域内。每个map中的block在物理硬盘上的存储程序是不间断的，但每个map中的所有block肯定是属于一个文件的，即FileSize=N×MAP×1024（Block）。 虚拟机数据恢复过程：vmfs中如果某文件被删除，在底层数据中只是删除了该文件的索引项，理论数据内容和指向数据map并没有被删除。1、应用北亚企安自研的数据提取工具将整个文件系统外面的所有闲暇map提取进去。2、在提取进去的map中找到合乎快照文件头构造的map。3、依据文件构造提取剩下的文件碎片。4、将所有数据提取实现后，联合原有的vmdk合成一个新的vmdk。5、挂载新合成的vmdk文件，解释该vmdk文件外面的数据即可。

服务器数据恢复环境：一台IBM某型号服务器上有16块FC硬盘组建RAID阵列。下层linux操作系统，ext3文件系统，部署有oracle数据库。 服务器故障&检测：服务器上跑的业务忽然解体，管理员发现服务器上有2块磁盘的指示灯显示黄色。通过IBM storage manager查问服务器状态，发现服务器报告逻辑卷状态失败。物理硬盘状态为：一块盘报告“正告”，指示灯显示黄色的2块盘报告“失败”。通过IBM storage manager将以后服务器的日志残缺备份。北亚企安数据恢复工程师在备份服务器日志的同时剖析日志内容，获取数据复原所须要的逻辑卷信息。 服务器数据恢复过程：1、将服务器中所有硬盘编号标记后从服务器内取出，由硬件工程师对所有硬盘进行硬件故障检测，通过检测发现16块盘均能够读取。针对16块盘的SMART状态进行检测，通过检测发现在IBM storage manager中报告“正告”的那块盘的SMART状态也报告为“正告”，后果统一。2、在windows环境下将辨认进去的FC盘在磁盘管理器中标记为脱机状态，而后对这些磁盘进行扇区级别全盘镜像，将原始磁盘中的所有物理扇区镜像到windows零碎下的逻辑磁盘并以文件模式保留。在镜像过程中发现SMART状态报告为“正告”的磁盘镜像速度异样，windows环境下的个别应用软件无奈对其进行操作，联合后面的检测后果能够判断该盘应该存在损坏/不稳固的扇区。3、应用业余硬盘镜像设施对这块SMART状态报告为“正告”的磁盘进行镜像，在镜像过程中察看发现该盘的坏道并不多，然而存在大量的读取响应工夫长的不稳固扇区，于是调整镜像策略，批改“遇到坏道跳过扇区数”和“响应等待时间”等参数后持续对该盘进行镜像。4、所有其余磁盘（除了SMART状态报告为“正告”的磁盘）镜像实现后，查看镜像过程中生成的日志，发现在IBM storage manager和硬盘SMART状态中均没报错的另外一块磁盘中也存在坏道，指示灯显示黄色的2块盘也存在大量不法则的坏道散布，依据坏道列表定位到指标镜像文件剖析发现，ext3文件系统的一些要害源数据信息曾经被坏道毁坏，只能期待SMART状态报告为“正告”的磁盘镜像结束后，通过同一条带进行xor以及依据文件系统上下文关系手动修复被损坏的文件系统。5、SMART状态报告为“正告”的磁盘镜像实现，然而之前为了最大限度做出无效扇区以及为了爱护磁头而设置的拷贝策略会主动跳过一些不稳固扇区，所以该盘的镜像是不残缺的。调整拷贝策略，持续镜像被跳过的扇区，直到该盘所有扇区全副镜像进去。6、将服务器中16块硬盘的物理扇区镜像实现后，在windows平台下应用软件将所有镜像文件全副开展。通过对ext3文件系统的逆向剖析以及对日志文件的剖析，获取到16块FC盘的盘序，RAID的块大小，RAID的校验走向和形式等信息。7、利用这些raid相干信息虚构重组RAID，RAID重构实现后对ext3文件系统进行解析。8、和用户沟通后，数据恢复工程师提取出了一些oracle的dmp文件，由用户尝试进行复原。复原的过程中oracle报告imp-0008谬误。北亚企安数据库工程师仔细分析导入dmp文件的日志文件，发现提取进去的dmp文件存在问题。9、从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。又通过数小时的致力，北亚企安数据恢复工程师从新提取了dmp文件和dbf原始库文件。将复原进去的dmp文件移交给用户进行导入，这次导入一切顺利，没有报错。对复原进去的dbf原始库文件进行校验，后果所有文件均通过测试。通过认真核检测后，用户认可数据恢复后果，本次服务器数据恢复工作实现。

服务器数据恢复环境：一台网站服务器中有一组由6块磁盘组建的RAID6磁盘阵列，操作系统层面运行MySQL数据库和寄存一些其余类型文件。 服务器故障：该服务器在工作过程中，raid6磁盘阵列中有两块磁盘先后离线，不晓得是管理员没有留神或者没有器重这个状况，没有为该raid6磁盘阵列更换离线磁盘。当第三块硬盘离线后，该raid6阵列解体，服务器瘫痪，该服务器上跑的业务停摆。如果更换硬盘重新组建阵列，则阵列中的所有数据会全副失落。服务器管理员尝试通过市面上比拟风行的数据恢复软件对服务器中的数据进行抢救，然而仍有大部分数据失落无奈复原。管理员求助咱们数据恢复核心，要求复原服务器中所有数据。 服务器数据恢复过程：1、将故障服务器内所有硬盘编号后取出，通过硬件工程师检测没有发现有硬盘存在显著的硬件故障，都能够失常读取数据。以只读形式将所有磁盘进行扇区级别的全盘镜像，镜像实现后依照编号将所有磁盘还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、服务器磁盘阵列中3块硬盘同时掉线的概率能够忽略不计，要复原磁盘阵列中的数据首先须要搞清楚这几块硬盘离线的先后顺序，找到最初离线的硬盘。如果最初离线的那块硬盘存在硬件故障则修复硬件故障，而后提取数据。依据该raid阵列的存储构造剖析raid构造参数，而后利用这些参数重组raid。3、本案例服务器中的raid6磁盘阵列应用的是双校验模式：第一个校验形式是一般的oxr（异或运算），第二个校验形式是reed-solmon算法。个别状况下通过第一个校验形式即可复原数据，然而本案例中radi6阵列中的前两块离线硬盘很早之前就曾经掉线，不具备数据恢复的条件，所以无奈通过第一种校验形式来复原数据。第二种校验形式比较复杂，所以管理员通过市面上罕用的数据恢复软件复原进去的数据大量缺失，且数据库无奈应用。4、北亚企安数据恢复核心工程师团队对reed-solomon算法进行过技术攻关，领有通过reed-solomon算法复原数据的理论案例教训。通过一番致力，北亚企安数据恢复工程师通过剖析获取到该raid6磁盘阵列的要害参数并提取出残缺的镜像数据。5、通过用户方管理员的验证，确认所有数据胜利复原，数据库能够应用，本次服务器数据恢复工作实现。

服务器数据恢复环境：一台服务器通过FreeNAS（本案例应用的是UFS2文件系统）实现iSCSI存储，整个UFS2文件系统作为一个文件挂载到ESXi虚拟化零碎（装置在另外2台服务器上）上。该虚拟化零碎一共有5台虚拟机，其中有3台虚拟机中的数据比拟重要：一台虚拟机上部署了ASP.net+SqlServer和PHP+mysql；第二台虚拟机装置的FreeBSD，部署了MySQL数据库；第三台虚拟机寄存的是代码数据。本案例利用构架档次：FreeNAS(UFS2文件系统–> 一个大的稠密模式的文件) –> ESXi (VMFS文件系统层) -> 单台虚拟机的虚构磁盘 (windows-NTFS文件系统/FreeBSD-UFS2文件系统)。 服务器故障：作为iSCSI存储的服务器在失常运行过程中异样断电，重启后虚拟化零碎无奈连贯该服务器，FreeNAS的UFS2文件系统呈现问题，管理员对UFS2文件系统进行了修复，然而ESXI虚拟化零碎无奈辨认原有的数据和UFS2文件系统。 服务器数据恢复过程：1、对FreeNAS层做只读镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止数据恢复操作对原始数据造成二次毁坏。2、基于镜像文件剖析整个存储，只发现了一个文件名为iscsidata的、大小数百GB的文件。3、依据UFS2文件系统的二进制构造定位到iscsidata文件的Inode数据，通过检测发现该文件被重建过，inode指针指向的数据量很少，在FreeNAS层无奈解决问题，所以就无奈进行下一步的VMFS层剖析。4、因为iscsidata文件重建过，过程和大小都和原iscsidata文件统一，应该有局部指针块被笼罩。原iscsidata文件的inode和新建的iscsidata文件的inode在同一个地位，尝试搜寻没有发现其它有用的inode。5、北亚企安数据恢复工程师编写程序收集有用的指针块。因为iscsidata文件采纳的稠密模式，放宽收集条件后收集到了大量三级指针块和二级指针块。6、通过剖析发现所有收集到的三级指针块都是有效的，没有找到iscsidata文件应用的三级指针块，应该是在新建iscsidata文件时被笼罩。7、剖析收集到的二级指针块并对大量的二级指针块的指向数据进行DUMP，而后从磁盘中的数据定位到二级指针。通过这种形式获取到大量DUMP的数据。8、剖析VMFS层。因为VMFS从新格式化过，原始UFS2的指针已失落，所以VMFS元文件不可用。9、通过单台虚拟机层(windows(NTFS)和FreeBSD(UFS2)的文件系统构造)，向上定位到VMFS层，而后通过VMFS层定位到DUMP出的单个64GB文件。通过屡次组合，最终将三台重要虚拟机的虚构磁盘完全恢复。将复原出的网页数据和数据库数据上传到筹备好的零碎中，拉起利用并对数据进行检测，没有发现任何问题。10、通过用户方的认真检测后，确认3台重要虚拟机中的数据胜利复原，认可本次数据恢复后果。本次服务器数据恢复工作实现。

服务器数据恢复环境：一台服务器共装备32块硬盘，组建了4组RAIDZ，Windows操作系统+zfs文件系统。 服务器故障：服务器在运行过程中忽然解体，通过初步检测检测没有发现服务器存在物理故障，重启服务器后故障仍旧，须要复原服务器内的大量数据。通过北亚企安数据恢复工程师的初步检测，发现故障服务器中4组raidz里有两组raidz中的热备盘启动。其中第一组raidz启用了一块热备盘，之后又有一块硬盘掉线；第二组raidz第一块磁盘离线后又有2块硬盘掉线，总共启用了三块热备盘。这两组raidz中硬盘离线后均启用了热备盘替换坏盘，热备盘上线后这2组raidz中又呈现其余硬盘离线的状况。为了失去正确数据，zpool在每次读取数据时都会进行校验。第二组raidz热备盘上线后又有硬盘离线，服务器彻底解体。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，以只读形式将所有磁盘做全盘镜像，镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、ZFS治理的存储池与惯例RAID不同。惯例RAID在存储数据时会依照特定的规定组建存储池，并不思考文件在子设施上的地位；而ZFS在存储数据时会为每次写入的数据调配适当大小的空间，通过计算获取指向子设施的数据指针。ZFS的这种个性让RAIDZ在缺盘时无奈间接进行校验失去数据，必须将整个ZPOOL作为一个整体进行解析。3、手工截取事务块数据，北亚企安数据恢复工程师编写程序获取最大事务号入口。获取文件系统入口：4、获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序进行地址解析。解析数据指针：5、获取到文件系统入口点在各磁盘散布状况后，数据恢复工程师手工截取&剖析文件系统内部结构。入口散布所在的磁盘组无缺失盘，可间接提取信息。依据ZFS文件系统的数据存储构造顺利找到映射的LUN名称，进而找到其节点。6、因为在此ZFS版本与开源版本有较大差异，无奈应用原先开发的解析程序进行解析，所以数据恢复工程师只能从新编写数据提取程序。7、因为磁盘组内缺盘个数较多，每个IO流都须要通过校验失去，提取进度极为迟缓。与用户方沟通后得悉此ZVOL卷映射到XenServer作为存储设备，用户需的文件在其中一个大小约为2T的vhd内。提取ZVOL卷头部信息，依照XenStore卷存储构造进行剖析，发现2T vhd在整个卷的尾部，计算失去其起始地位，从起始地位开始提取数据。8、Vhd提取结束后，对其外部的压缩包、图片、视频等文件进行验证，均可失常关上。9、用户发通过验证后，确定复原进去的文件数量与零碎自动记录的文件数量差不多，极小局部失落的文件可能是因为这些文件是新生成的还未刷新到磁盘。用户验证文件的可用性，文件全副可失常关上，本次数据恢复工作实现。

Ceph存储根本架构：Ceph存储可分为块存储，对象存储和文件存储。Ceph基于对象存储，对外提供三种存储接口，故称为对立存储。Ceph的底层是RADOS(分布式对象存储系统)，RADOS由两局部组成：OSD和MON。MON负责监控整个集群，保护集群的衰弱状态，保护展现集群状态的各种图表，如OSDMap、MonitorMap、PGMap和CRUSHMap。OSD负责存储数据、复制数据、均衡数据、复原数据，与其它OSD间进行心跳查看等。通常状况下一块硬盘对应一个OSD。 Ceph数据的存储过程：无论应用哪种存储形式（对象、块、文件），存储的数据都会被切分成对象（Objects)。 存储池：不同用户因为不同的目标把对象存储在不同的存储池里，这些对象散布于OSD上。对象保留在不同的存储池（Pool）中，是对象存储的逻辑组，对应不同的用户。存储池治理着归置组数量、正本数量、和存储池规定集。 归置组：归置组（PGPlacementGroup）是对象池的片段，Ceph依据对象的Oid和一些其余信息做计算操作，映射到归置组，有数的对象被划分到不同的归置组。PG是一个逻辑概念，它在数据寻址时相似于数据库中的索引。每个对象都会固定映射进一个PG中，所以当咱们要寻找一个对象时，只须要先找到对象所属的PG，而后遍历这个PG就能够了，无需遍历所有对象。而且在数据迁徙时，也是以PG作为根本单位进行迁徙。 OSD：最初PG会依据管理员设置的正本数量进行复制，而后通过crush算法存储到不同的OSD节点上，最终把PG中的所有对象存储到OSD节点上。 BlueStore：新版本中，Ceph默认以Bluestore存储引擎，作为RADOS中OSD的ObjectStore存储底层实现BlueStore整体架构。 存储空间：BlueStore将整个存储空间分为3个局部：WAL，DB，SLOW慢速(Slow)空间：次要用于存储对象数据，由BlueStore治理。高速(DB)空间：存储blufs和rocksdb产生的数据，由BlueFS间接治理，如果不存在或者DB设施空间有余，则抉择Slow类型设施空间。超高速(WAL)空间：次要存储RocksDB的WAL（即.log）文件，由BlueFS间接治理，如果不存在或者WAL设施空间有余，则逐级降级抉择DB、SLOW分区。 Rocksdb：BlueStore应用Rocksdb作为本人元数据存储的底层实现，将各种元数据以kv型记录的形式存在数据库中。写入机制：任何元数据的写入都会先写到WAL，而后再写入MemoryTable(Memtable)。当一个Memtable写满了之后，就会变成immutable的Memtable，RocksDB在后盾会通过一个flush线程将这个Memtableflush到磁盘，生成一个SortedStringTable(SST)文件。 BlueFS：BlueFS与通用文件系统不同，是Bluestore专为Rocksdb所设计的精简文件系统。BlueFS的文件和目录的元数据以日志事务的模式保留在日志文件中，在上电过程中，replay日志文件中的事务，就能够加载所有的元数据到内存中。 北亚企安针对Ceph的数据恢复流程：1、制作磁盘镜像，用于数据提取和备份。2、提取BlueFS中数据库文件。从磁盘镜像的分区获取超级块，失去日志的节点信息。回放整个日志中的事务，失去目录构造和数据库文件节点信息，依据数据库文件节点信息提取数据库文件。提取从每个OSD提取进去的数据库中的object记录。3、对于损坏的数据库，依据文件格式提取数据库完整文件中的object记录。4、解析object记录，从各镜像上提取对应的object数据。5、依据object的id按序组合卷文件的所有object数据块，还原整个卷数据。6、修复卷的文件系统和其中文件。对于损坏缺失水平不高的卷文件系统，尝试修复损坏的卷，失去卷中的文件。对于有固定格局的文件，尝试修复损坏文件。

XSAN数据恢复环境：昆腾存储，MAC OS操作系统，划分了9个数据卷（1个META信息卷，8个DATA信息卷），寄存视频类数据，MXF、MOV等格式文件。 XSAN故障&剖析：将存储空间从XSAN架构迁徙到STORNEXT架构，迁徙实现后发现存储空间中数据全副失落。北亚企安数据恢复工程师剖析META信息卷，读取其中的元信息，发现存储空间中数据失落的起因是迁徙的时候误将整个存储系统格式化。 XSAN数据恢复过程：1、将故障存储中所有磁盘编号后取出，以只读形式进行全盘镜像备份，备份实现后将所有磁盘依照编号还原到原存储中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 2、基于镜像文件剖析META信息卷中的元信息。版本差别起因导致此XSAN版本的元信息结构与之前的XSAN版本元信息结构存在差别，目录项的解析形式与节点的解析形式都有肯定的变动。在剖析出残缺的元信息结构后，北亚企安数据恢复工程师编写脚本扫描META卷中的全副目录和节点信息，并写入到数据库中。 目录块截图： 节点截图： 数据库信息截图： 3、尽管存储系统被格式化，然而大部分节点和目录块信息还保留得比拟残缺，只是有大量的节点和目录块被零碎重置，所以局部文件或目录信息失落。这些目录信息的失落导致局部文件的目录构造断开，无奈重构残缺的目录树并提取文件。进一步剖析节点和目录块的信息，北亚企安数据恢复工程师重构修复局部断开的目录树，针对无奈修复的目录树，数据恢复工程师留在前面进行非凡解决。 4、提取数据。依据用户方的需要，分三步提取数据：a、针对优先级别和实效性十分高的局部文件，依据用户方提供的文件信息列表编写脚本，读取数据库并重构文件的目录树，针对列表中的文件进行批量提取复原。b、针对文件量大、优先级较低、且用户方无奈提供具体的文件信息或者仅能提供文件上一层或几层的目录信息的局部文件。依据用户方提供的一些目录信息编写脚本，读取数据库并重构残缺目录树，针对目录进行子文件或子目录的提取复原。c、遍历整个数据库，读取数据库中的全副残余文件信息，针对目录树残缺的文件，重构残缺目录树；针对局部下层目录树断开的文件，重构其局部目录树。而后提取数据库中残余未提取的全副文件。 用户方提供的文件信息列表： 数据提取过程截图： 5、通过用户方对复原进去的数据进行验证后，确认数据文件残缺可用，视频文件能够失常播放，工程文件能够失常编辑。本次数据恢复工作实现。

vsan数据恢复环境：一套VMware vSAN超交融基础架构，全闪存，开启压缩重删。共11台服务器节点。每台服务器节点上配置1块PCIE固态硬盘和8-10块SSD固态硬盘。每个服务器节点上创立1个磁盘组，每个磁盘组将1个PCIE固态硬盘辨认为2个硬盘作为缓存盘，将8-10个SSD固态硬盘作为容量盘，独特组成vSAN存储空间，用来存储虚拟机文件。 vsan故障&检测：vSAN中一台服务器节点的PCIE缓存盘产生故障，导致vSAN逻辑架构呈现故障，2台虚拟机磁盘组件呈现问题，虚拟机无奈失常应用。将11台节点服务器中的所有磁盘编号后取出，以只读形式做全盘镜像备份，备份实现后将磁盘依照编号还原到原节点服务器中，后续的数据分析和数据恢复操作都基于镜像文件，防止对原始磁盘数据造成二次毁坏。扫描&剖析全副镜像文件，发现因为版本更新和开启了压缩重删机制，底层构造差别较大。针对这种状况的数据恢复，难点在于压缩和重删的算法，因为须要大量数据碰撞测试和大量代码来测试压缩和重删算法。 vsan数据恢复过程：1、基于镜像文件剖析底层数据。依据底层记录的磁盘ID等信息，将节点、磁盘组、缓存盘、容量盘等信息及对应关系进行整顿记录。2、尝试在底层搜寻&剖析组件信息，后果发现组件信息被压缩，无奈进行剖析。3、测试压缩和重删。因该vSAN集群开启了压缩重删机制，底层数据结构产生很大的变动。北亚企安数据恢复工程师搭建雷同版本的环境，在搭建好的环境中通过大量数据碰撞测试来钻研压缩重删的算法和存储构造。4、通过大量数据碰撞测试钻研压缩重删算法，因为不确定该vSAN集群的采纳了何种压缩算法，所以北亚企安数据恢复工程师只能通过大量法则数据进行逆向推理确定其压缩算法，而后解压缩。压缩块：解压后：5、解析重删位图。通过大量数据测试确定压缩位图地位、记录形式、位图索引块大小等，从而获取位图索引形式，解析重删位图。6、因为VSAN中所有文件都是以对象的形式存在，每个对象会被宰割为多个组件。北亚企安数据恢复工程师编写程序扫描组件信息，依据组件中的runlist找到每个数据块和该块在组件的逻辑地位，而后编写程序提取残缺组件。7、依据组件信息中的形容信息将组件依照形容信息中记录的RAID级别和各个组件在对象中的逻辑地位进行组合，拼接出残缺的对象，即残缺的vmdk文件。因为每个组件可能会有局部数据留在缓存盘上，并没有写入到容量盘中，所以北亚企安数据恢复工程师编写程序将缓存盘上的数据刷新到对应的组件或对象中。8、因为本案例中虚构磁盘应用Windows下DFS分布式文件系统并且开启重删机制，无奈间接提取数据。新建DFS环境，将合并实现的虚构磁盘挂载到该环境下，挂载后可间接拜访数据。9、由用户方对数据进行检测，通过检测确认复原进去的数据残缺可用。本次数据恢复工作实现。

SQL SERVER数据库故障类型：1、SQL SERVER数据库文件被删除。2、SQL SERVER数据库所在分区格式化。3、SQL SERVER数据库文件大小变为“0”。4、应用备份还原数据库时笼罩原数据库。 SQL SERVER数据库故障起因：1、人为误操作。2、文件系统损坏，设施主动做磁盘检测。 SQL SERVER数据库故障体现：数据库文件（MDF、NDF或LDF）失落，数据库处于“置疑”状态。数据库数据恢复至晚期数据。 SQL SERVER数据库数据恢复计划：1、将故障设施中所有磁盘以只读形式做全盘镜像，后续的数据分析和数据恢复都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、剖析原来的文件系统格局。3、查找文件目录索引及文件索引信息。如果无奈找到其文件索引，北亚企安数据恢复工程师会通过MDF（或NDF）文件内部结构剖析全盘进行碎片。北亚企安数据恢复工程师通过重组碎片生成数据库文件。4、附加数据库文件，对数据库做残缺的DBCC检测。 SQL SERVER数据库数据验收过程：1、对修复好的数据库文件进行附加。2、附加后对数据库做DBCC检测。3、对表进行数据查问，测验数据的最初更新日期。

SQL SERVER数据库故障类型：SQL SERVER数据库MDF（NDF）或LDF损坏。 SQL SERVER数据库故障起因：1、数据库正在操作过程中，机器忽然断电。2、人为误操作。 SQL SERVER数据库MDF（NDF）或LDF损坏的故障体现：1、数据库在企业管理器中体现为“置疑”状态；2、附加数据库后，做DBCC检测，报“并闩锁”谬误；3、附加数据库时提醒“823谬误”；4、附加数据库提醒日志谬误；5、进行数据查问时报错。 SQL SERVER数据库数据恢复计划：1、将损坏的SQL SERVER数据库进行全库冷备份。2、依据MDF（或NDF）文件本身构造应用北亚企安自主开发的SQL SERVER数据库检测软件检测数据库外部逻辑构造，确定复原数据库数据的可能性。3、手工备份损坏的数据库文件（MDF/NDF和LDF），确保数据恢复的操作可回溯。4、应用北亚企安自主开发的无日志附加数据库软件附加数据库。5、如果数据库文件可失常附加，对数据库做DBCC检测，确定数据损坏的水平及损坏的地位。a、如果数据库提醒“823谬误”和“并闩锁谬误”，通常状况下是因为数据库的“索引”页出错。b、如果数据库损坏的是“索引”页，能够通过数据库内高低页内容进行计算，而后手工修复损坏页。c、如果数据库损坏的是“数据”页，能够通过北亚企安自主开发的SQL SERVER数据库复原工具对数据进行提取和重组。 SQL SERVER数据库数据验收：1、将修复好的SQL SERVER数据库文件进行附加；2、附加后对SQL SERVER数据库做DBCC检测；3、对重要表进行数据查问，测验数据的更新日期。

服务器数据恢复环境：基于UNIX零碎，软件层级的数据劫难。 服务器故障：1、存储构造出错。2、删除数据。3、文件系统格式化。4、其余起因导致的数据失落。 服务器数据恢复的可能性剖析：1、存储构造出错。无论谬误呈现在RAID还是卷组、分区、片区（不同的UNIX有不同的存储管理形式），只有存储通过一个或几个文件系统组织治理数据，文件系统自身没有被毁坏，呈现问题后也没有进行任何破坏性的操作，复原数据的概率十分高。2、删除数据。如果删除数据后没有新数据写入：a、AIX JFS/JFS2文件系统下能够残缺复原数据。b、SGI XF文件系统下能够残缺复原数据。c、Vxfs文件系统下删除数据，如果文件数量少，北亚企安自研算法能够残缺复原Vxfs文件系统数据；如果文件数量比拟多，则依照节点失落状况解决。d、其它如SCO HTFS、UFS文件系统下删除数据后，节点通常会失落。UNIX类文件系统节点失落意味着文件的属性（大小、日期戳、权限、与名称的关联等）无奈获取，在某些状况下索引也无奈找到。遇到这类问题，北亚企安数据恢复工程师通过须要复原文件的外部特色来复原数据。如果是规律性强的文件如ORACLE之类的数据库文件，复原概率很高；然而像压缩包、多媒体文件等规律性不强的数据不容易复原。如果删除数据后有新的数据写入，写入的新数据所笼罩的区域无奈复原。3、文件系统格式化。如果格式化后没有新的数据写入：a、AIX JFS 及 JFS2文件系统格式化前的大多数文件能够复原。b、SGI XFS文件系统格式化前的大多数文件能够复原。c、Vxfs文件系统格式化后，须要剖析新构造与格式化前的构造的重叠局部，复原的概率介于AIX JFS2格式化与UFS格式化之间。d、其余文件系统如UFS格式化后，节点会失落，这种状况与删除数据的状况雷同，参考上述删除数据后节点失落的复原可能性剖析。如果格式化后有新的数据写入，写入的新数据所笼罩的区域无奈复原。4、其余起因导致的数据失落。数据失落本质上能够归结为：节点是否失落、索引是否失落、数据自身是否失落。删除、格式化能够了解为节点和索引失落；而数据自身失落就再无复原数据的意义了。如果某个文件节点、索引、数据自身都能够找到，则能够残缺复原数据。

服务器数据恢复环境：HP EVA某型号存储，存储中一共有23块磁盘，下层映射给一台windows server服务器上。 服务器故障&检测&剖析：该EVA存储上三块磁盘指示灯显示黄色，此时存储设备还能失常工作。运维更换显示黄色的指示灯对应的硬盘，在更换硬盘的过程中，又有一块硬盘对应指示灯显示黄色离线，这时存储解体无奈应用。北亚企安数据恢复工程师将故障存储中所有磁盘编号取出，由硬件工程师对指示灯显示黄色离线的4块磁盘进行硬件故障检测，通过检测发现这4块硬盘都呈现不同水平的磁头和盘片损坏状况，后续数据恢复只能通过剩下的19块完整的硬盘进行。 服务器数据恢复过程：1、将故障服务器上19块完整的磁盘以只读形式做全盘镜像备份，备份实现后将所有磁盘依照编号还原到原存储设备中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、通过头部信息解析根本信息。3、解析RSS组信息。4、解析lun信息。5、通过lun信息提取MAP位图信息，通过MAP位图信息提取数据块，将提取进去的数据块组合成逻辑卷并解析。6、由用户方对复原进去的数据进行检测，通过重复检测后确认复原进去的数据残缺无效。本次数据恢复工作实现。 服务器数据恢复论断：本案例故障是存储中多块硬盘离线导致存储解体不能失常拜访，离线硬盘的盘片都有不同水平的划伤，无奈复原离线硬盘的数据。因为北亚企安数据恢复工程师团队对EVA存储底层构造做过深入研究，并且积攒了大量解决此类故障的教训，所以能在离线硬盘数据缺失的状况下比较顺利复原EVA存储中的数据。

Oracle数据库故障&剖析：北京某单位Oracle 11g R2数据库误执行truncate table CM_CHECK_ITEM_HIS，表数据失落，查问该表时报错。数据库备份无奈应用，表数据无奈查问。Oracle数据库Truncate数据的机理：执行Truncate命令后，ORACLE数据库会在数据字典和Segment Header中更新表的Data Object ID，然而不会批改理论数据局部的块。Truncate数据会导致数据字典和Segment Header的DATA_OBJECT_ID与后续的数据块中的不统一，ORACLE服务过程在读取全表数据时就不会读取到曾经被TRUNCATE的记录，理论数据其实并没有被笼罩。 Oracle数据库数据恢复过程：为了爱护用户隐衷和数据安全，咱们没有将复原该oracle数据库数据的过程演示进去，北亚企安数据恢复工程师还原了和该案例雷同的oracle故障环境，用来演示如何复原Oracle数据库Truncate数据。1、通过Scott用户创立表emp1，间断复制emp表屡次，总记录数为7340032条。truncate表emp1，之后没有进行任何增删改的操作。通过查问，Oracle数据库中表emp1的记录为0条。2、剖析system表空间文件，找到truncate表（表emp1）的原始数据所在的地位。3、解析表emp1所在的数据文件，找到truncate的数据。4、将truncate的数据插入到数据库中。 Oracle数据库数据恢复后果：解析system01.dbf文件，找到truncate的数据所在的地位，找到被删除的数据。解析truncate表所在的数据文件，将truncate的数据插入到数据库中。这时在oracle数据库中查找被truncate的表，发现数据曾经回来了，备份数据。Exp导出scott用户。

服务器数据恢复环境：北京某单位有一台EMC某型号存储，有一组由10块STAT硬盘组建的RAID5阵列，另外2块磁盘作为热备盘应用。RAID5阵列下层只划分了一个LUN，调配给SUN小机应用，下层文件系统为ZFS。 服务器故障：存储RAID5阵列中有2块硬盘损坏离线，只有一块热备盘激活，RAID5阵列瘫痪，下层LUN无奈失常应用。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，由硬件工程师对所有磁盘做硬件故障检测，通过检测没有发现有硬盘存在物理故障和坏道。磁盘没有发现物理故障和坏道，初步推断是某些磁盘读写不稳固导致故障产生。EMC控制器的磁盘检测策略十分严格，一旦检测到某些磁盘性能不稳固，EMC控制器极有可能会断定这些磁盘为坏盘，将认定为坏盘的磁盘踢出RAID阵列。一旦RAID阵列中掉线的盘到达到该RAID级别容许掉盘的极限值，就会导致RAID阵列解体不可用，因为EMC存储的LUN都是基于RAID阵列的，RAID解体会导致基于该RAID阵列的LUN不可用。2、将故障存储中所有磁盘以只读形式做全盘镜像备份，镜像实现后依照编号将所有磁盘还原到原存储中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后发现源磁盘的扇区大小为520字节，应用工具将镜像数据做520字节To512字节的转换。3、基于镜像文件剖析底层RAID5阵列的相干信息。通过剖析发现发现其中有2块盘（8号盘和11号盘）齐全没有数据，从治理后台上显示这2块盘是Hot Spare，8号盘替换了离线的5号盘。尽管8号盘作为热备盘胜利激活，但该RAID级别为RAID5，因为有2块盘离线，所以该RAID5阵列还缺失一块硬盘，所以数据没有同步到8号盘中。持续剖析其余10块硬盘，剖析数据在硬盘中的散布法则、RAID条带的大小、盘序等相干信息。4、依据下面步骤剖析进去的RAID信息虚构重构原RAID。因为整个RAID阵列中一共掉线两块盘，须要剖析这两块盘掉线的程序。通过剖析发现有一块盘在同一个条带上的数据和其余盘显著不一样，因而初步判断此盘可能是先掉线的。应用北亚企安自主开发的RAID校验程序对这个条带做校验后确认先掉线的那块硬盘。5、因为LUN是基于RAID阵列的，实现原RAID阵列的重组后剖析LUN在RAID阵列中的调配信息和LUN调配的数据块MAP。依据LUN相干信息解释LUN的数据MAP并导出LUN的所有数据。6、应用北亚企安自主开发的ZFS文件系统解释程序对生成的LUN做文件系统解释，在解释某些文件系统元文件的过程中程序报错。开发工程师对程序做debug调试并分析程序报错起因，通过数小时的剖析与调试，发现无法解释文件系统的的起因是存储瘫痪导致ZFS文件系统中某些元文件损坏。人工修复这些损坏的元文件。7、修复实现后解析ZFS文件系统，解析所有文件节点及目录构造。8、由用户方工程师对复原进去的数据进行验证，验证过程中没有发现问题，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：一台某品牌服务器通过一张同品牌某型号RAID卡将4块STAT硬盘组建为一组RAID10阵列。下层部署Xen Server虚拟化平台，虚构机上安装的是Windows Server操作系统，包含系统盘 +数据盘两个虚拟机磁盘，作为Web服务器应用，寄存网站代码、SQL Server数据库以及其余网站数据。 服务器故障&故障起因剖析：机房意外断电导致服务器中一台VPS（Xen Server虚拟机）不可用，虚构磁盘文件失落。北亚企安数据恢复工程师将故障服务器中所有磁盘编号后取出，以只读形式将所有磁盘残缺镜像到筹备好的备份空间，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。备份实现后将所有磁盘依照编号还原到原服务器中。基于镜像文件剖析底层数据发现故障服务器中的虚拟机磁盘是以LVM构造治理的，即每个虚拟机的虚构磁盘都是一个LV，虚构磁盘模式是精简模式。LVM的相干信息在Xen Server中都有记录。查看“/etc/lvm/backup/“下LVM的相干信息，并没有发现存在损坏的虚构磁盘，能够初步判断LVM的信息曾经被更新了。持续剖析底层，查找到还未更新的LVM信息。依据未更新的LVM信息找到虚构磁盘的数据区域，发现该区域的数据已被毁坏。当初能够确定虚拟机不可用的起因是虚拟机的虚构磁盘被毁坏，导致虚拟机中的操作系统和数据失落。核查这片区域，发现该区域有很多数据被毁坏了，但还是发现了很多数据库的页碎片。因而能够尝试将许多数据库的页碎片拼接为一个可用的数据库。 服务器数据恢复计划：计划a：依据RAR压缩包的构造能够找到很多压缩包的数据开始地位，RAR压缩包文件的第一个扇区中会记录此RAR的文件名。因而将从用户那里拿到的备份数据库的压缩包文件名和目前找到的压缩包文件第一个扇区所记录的文件名相匹配，即可找到备份数据库压缩包的开始地位。找到压缩包的地位后仔细分析这片区域的数据，而后将此区域的数据恢复进去并重命名为一个RAR格局的压缩文件。尝试解压此压缩包，发现解压报错。仔细分析复原进去的压缩包，发现其中有局部数据被毁坏，解压报错。尝试应用RAR的修复工具解决后解压。后果修复实现之后解压进去的数据只蕴含网站的局部代码，并没有发现数据库的备份文件。因而能够判断在RAR压缩包中的数据库的备份文件曾经是损坏的。解压进去的局部网站代码： 计划b：计划a没有将数据库复原进去。北亚企安数据恢复工程师采纳计划b。依据SQL Server数据库的构造剖析数据库的开始地位。SQL Server数据库第9个页会记录本数据库的数据库名。在用户那里获取到数据库的名称之后，剖析底层找到此数据库的开始地位。在SQL Server数据库的每个页中都会记录数据库页编号以及文件号，依据这些SQL Server数据库特色，北亚企安数据恢复工程师编写程序去底层扫描合乎数据库页的数据。将扫描进去的数据库页碎片按程序重组成一个残缺MDF文件。通过MDF校验程序检测整个MDF文件的完整性。 验证数据：检测没问题之后，由数据库工程师搭建数据库环境，将重组后的数据库附加到搭建好的数据库环境中。查问相干表数据是否失常以及最新数据是否存在。检测没有问题后，在网站开发商的帮忙下用网站代码搭建好环境，将复原好的数据库发给用户在环境中配置好。通过用户验证后没有发现问题，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：一台服务器中有两组别离由4块SAS硬盘组建的raid5阵列，两组阵列下层划分LUN组建LVM构造，并被格式化为EXT3文件系统。 服务器故障&检测：RIAD5阵列中有一块硬盘故障离线，热备盘激活上线顶替离线硬盘。在热备盘上线同步数据的过程中，该RAID5阵列中又有一块硬盘离线，热备盘同步失败，该组RAID5阵列解体，下层的LVM构造被毁坏，EXT3文件系统无奈失常应用。硬件工程师对两块离线硬盘进行硬件故障检测，发现先离线的那块硬盘无奈辨认，应该是硬件问题，须要收盘修复。后离线的硬盘能够失常辨认。 服务器数据恢复过程：1、将故障服务器中故障RAID中所有磁盘编号后取出，通过硬件工程师的检测发现，发现先离线的磁盘无奈辨认。硬件工程师对这块硬盘进行了收盘操作。收盘后发现盘片磨损重大，无奈修复，只能对故障RAID5阵列进行缺盘解决。2、以只读形式将故障RAID5阵列中的其余成员盘进行全盘镜像备份，并且对另一组完整的raid5阵列中的全副磁盘进行全盘备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 3、基于镜像文件剖析硬盘底层数据，通过解析EXT3文件系统构造，剖析出两组raid5阵列的盘序、条带大小、校验方向等RAID构造相干信息。通过剖析，两组raid阵列块大小都为64K，校验方向为左同步，对故障raid进行重组时进行缺盘解决。依据剖析出的RAID构造相干信息重组两组raid5阵列。 4、重组出两组raid阵列后剖析两组raid中的底层数据，找出LVM构造信息。对LVM构造进行剖析，将两组raid中作为PV（LVM物理卷）的LUN导出，而后将两个PV重组，从新生成LVM逻辑卷。 5、LVM重组之后，解析LV（逻辑卷）中的EXT3文件系统，复原并导出其中的全副数据。 6、用户方工程师对复原进去的数据进行检测后，确认复原进去的数据残缺无效。本次数据恢复工作实现。

存储数据恢复环境：某单位一台存储，1个机头+4个扩大柜，有两组别离由27块和23块硬盘组建的RAID5阵列。其中由27块磁盘组建的那一组RAID5阵列解体，这组RAID5阵列寄存是Oracle数据库文件。存储系统下层共划分了11个卷。 存储故障&检测：存储内磁盘产生故障，存储设备上有两块盘的硬盘指示灯显示黄色，存储不可用，存储设备曾经过保。硬件工程师将故障存储中那组呈现故障解体的阵列中所有磁盘编号后取出，对该RAID5阵列中的27块硬盘做了硬件故障检测，发现其中有2块硬盘呈现坏道，SMART的谬误冗余级别曾经超过阈值。将25块失常的硬盘以只读形式进行全盘镜像，将2块发现有坏道的硬盘应用非凡伎俩进行解决后生成镜像文件。 收集&剖析故障存储日志信息，分析判断两块硬盘的掉线工夫，用数据较新的硬盘来复原数据。 存储数据恢复计划：计划a：把存储的所有硬盘都进行备份，而后通过原厂存储管理软件进行强制上线操作。计划b：剖析底层数据，利用剖析获取到的RAID5构造相干信息重组RAID，而后从底层提取数据，从新加载oracle数据库，调试下层利用。 存储数据恢复过程：1、首先依照计划a在模拟器上进行测试。2、通过存储设备原厂存储管理软件进行强制上线，强制上线之后raid处于降级状态。设置好热备盘，让热备盘顶上并同步数据。3、同步完之后，下层的卷能够间接应用了，数据齐全可见，下层利用也能够失常应用。北亚企安数据恢复工程师也没想到这么顺利，计划a就间接就搞定了，下层利用能够间接启动，通过用户方多方面测试，确认数据没有问题。4、将卷里的文件拷贝进去移交给用户方。本次数据恢复工作实现。

Ext4文件系统相干概念：块组：Ext4文件系统的空间被划分为若干个块组，每个块组内的构造大致相同。块组描述符表：每个块组都对应一个块组描述符，这些块组描述符对立放在文件系统的前部，称为块组描述符表。每个块组描述符大小为32字节，其次要形容块位图、i-节点位图及i-节点表的地址等信息。超级块(Superblock)：用于存储文件系统的配置参数(如块大小、总块数、i-节点数)和动静信息(以后闲暇块数和i-节点数)。Ext4文件系统的超级块(Superblock)开始于1024字节处，即2号扇区。i节点：形容文件的工夫信息、大小、块指针等信息。块组描述符和超级块在块中的地位：当块大小为2个扇区时，0号块是疏导程序或者保留块，超级块起始于1号块。当块大小为4个扇区时，疏导程序或者保留块位于0号块的前两个扇区，超级块位于0号块的后两个扇区。当块大小为8个扇区时，疏导程序或者保留块位于0号块的0-1号扇区，超级块位于0号块的2-3号扇区。Ext4文件系统构造及第一个块组构造： Ext4文件系统故障&初检&剖析：某公司服务器Ext4文件系统umount失败，管理员执行fsck操作查看一致性，导致Ext4文件系统mount不上并报错，报错信息：“mount:wrong fs type,bad option,bad superblock”。日志和数据的不统一导致失常文件系统数据被笼罩的状况在Ext3、Ext4文件系统中产生频率较高。因为.journal日志文件保留了缓冲数据，能够通过.joumal日志文件找到相应信息并重建源文件。通过查看MBR分区表得悉本案例中的Linux操作系统分了两个分区：替换分区+Ext4文件系统。北亚企安数据恢复工程师通过对该Ext4文件系统的剖析，失去以下信息：1、块大小为固定的4KB，即8个扇区。2、超级块(Superblock)起始地位在1024字节处，即2号扇区，大小为2个扇区。3、块组形容表从第一个块开始，即从4096字节处开始。 服务器数据恢复过程：1、将故障服务器上硬盘取出，检测后没有发现硬件故障。以只读形式将磁盘做全盘镜像，镜像实现后依照原样将磁盘还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、用工具关上Ext4文件系统，能够看到0-23扇区的数据(包含超级块和块组描述符)被日志记录笼罩。Ext3、Ext4文件系统的日志页以C0 3B 39 98结尾。 在journal日志中将超级块的备份查找进去，通过工具查找超级块信息，其标记是“53ef”。超级块0x18-0x1B处形容块大小，确定本案例块大小为4KB。查找超级块：通过超级块查看块大小：块大小： 3、因为原文件系统超级块损坏，所以复原文件时，要把这部分超级块信息粘贴回去，放在2号扇区开始，或1024字节处。做完以上操作，超级块备份某些中央与理论的超级块数值可能不统一，须要通过工具进行批改。对超级块所在的块组进行了批改，超级块在第0个块组里。 4、因为局部块组形容表被毁坏，所以须要在.journal日志文件里找到所有的块组形容表并把它们粘贴回去。.journal日志文件里的块组描述符表存储在超级块的前面，要找块组形容表能够先找到超级块，找到后将块组描述符表内容粘贴到4096字节处。5、复原某个文件夹比方kyproc文件夹里的数据时，咱们发现这些文件夹在WinHex里是不能关上的状态（如下图1所示），很显著这个目录损坏了。关上其节点信息，发现失常数据被日志填充（如下图2所示）。找到它的上一级目录，即var文件夹。右击点“open”，关上看到var文件里的所有文件的目录信息。找到要复原的kyproc目录的信息，12 32 EE 00是其i-节点号，10 00示意其目录项长度，06示意其文件名称长度，02示意其文件类型为目录（如下图所示）。在var文件夹的目录块下查找kyproc目录的地位（如下图所示），标红的地位是找到的后果。此地位显示所在块号为62399108。依据所在块号能够定位kyproc目录相应节点的地位。关上.journal日志文件，从外面找到其节点信息，把相应的信息粘贴回去。6、通过上述办法重建目录后开始重建目录里的文件。重建目录里的文件也是应用同样的办法：从.journal日志文件里找到相应的文件的节点信息，找到后粘贴回原来的地位，达到重建文件的目标。

硬盘数据复原环境&故障状况：某单位重要数据在一台WINDOWS操作系统的PC机上通过网络共享给公司员工应用。这台PC同时也连贯着打印机提供打印服务，很多员工间接将文件拷贝到这台PC上进行打印。该PC机上只有一块500G磁盘。该PC的F盘分区所有类型文件忽然全副无奈关上。故障体现：1、文件名称，工夫，门路完全正确，磁盘占用空间正确。2、关上jpg文件提醒：“windows照片查看器无奈关上此图片，因为照片查看器不反对此文件格式，或者您没有照片查看器的最新更新”。3、关上doc文件提醒："请抉择使文档可读的编码"，抉择任何一个编码后文件都是谬误的。4、关上docx文件提醒："无奈关上文件，因为内容有谬误"。5、关上xls文件提醒：“您尝试关上的文件的格局与文件扩展名指定的格局不统一，关上文件前请验证文件没有损坏且起源可信”。6、关上xlsx文件提醒："您无奈关上文件，因为文件格式或文件扩展名有效，请确定文件未损坏，并且文件扩展名与文件的格局匹配"。7、关上PDF文件提醒：“打开文档时产生谬误,文档已损坏且无奈修复”。8、其余类型文件均无奈失常关上。 故障检测后果&剖析：1、硬盘不存在无物理故障。除了F盘，其余分区数据均失常。2、无启用过任何加密。3、没有采纳第三方软件做过分区大小调整、合并。4、无操作系统问题和电脑Virus入侵。5、无其余异样操作。 将硬盘接入到平安(不加载盘符，不主动写数据，保障齐全只读)的操作环境中，发现文件系统底层失常，但数据区呈现谬误。以一个PDF文件为例，在工具中关上如下图： 一个失常的PDF文件，二进制构造肯定是以0x46445025(即ASCII的“%PDF”)作为结尾标记，而这个文件的结尾却是以0x71736712开始。将两者进行比拟，这显然是一种异或转换。通过计算，两者相差(异或)0x37。在本PDF文件的尾部同样发现了篡改。于是，在工具中选中文件所有内容，对选中块以0x37做字节异或(xor)： 保留后关上，文件失常。接下来对其余文件做剖析，发现篡改的算法均是全副文件对某个值xor，但此值不确定。按字节概率计算应该有256种可能，加上文件数量及类型泛滥，显然手动修改工作量太大。北亚企安数据恢复工程师剖析其xor加数的生成法则。过程如下：1、推断是否与门路相干：在同一门路下关上不同的文件剖析篡改的异或加数，发现不尽相同，排除。2、推断是否与文件名称相干：查找所有文件，按名称排序，找到雷同文件名称但大小不同的文件，关上后剖析篡改的异或加数，发现不雷同，排除。3、推断是否与类型相干：找到同一类型的几个不同文件，剖析篡改的异或加数，发现不雷同，排除。4、推断是否与存储的物理地位相干：在工具中按不同文件起始地位进行剖析篡改的异或加数，未发现相关性，排除。5、推断是否与文件头部相干：查找头部雷同的文件(有同一文件的不同更新，头部是雷同的)，进行剖析后也排除。6、推断尾部相干的可能性不大。如果前面剖析仍无奈失去法则，则需返回此项再做验证。7、推断是否与文件创建工夫相干：别离查找雷同创立工夫、雷同拜访工夫、雷同最初一次拜访工夫的2个文件，进行剖析，发现与此无关，排除。8、推断是否与大小相干：简略验证后，未举出反例颠覆，但须要齐全证实与大小相干，同时要失去算法，须要有足够多的样本。 针对是否与大小相干的验证：通过命令形式打印所有文件的大小： find ./ |xargs ls -ld 2>/dev/null|awk '{printf($5"\t\t"$9"\n");}' >../list.txt 用excel关上此列表文件。因篡改的异或加数只有一个字节。如果与大小相干，极有可能是和文件大小值的mod 256绝对应，于是在excel中计算所有文件大小值的mod 256。对mod 256的值进行排序。排序后：对雷同mod 256的文件进行篡改验证，未发现不符合规律者。基本上能够确定篡改值与文件大小值的mod 256存在映射关系。对所有可能做抽样剖析后，失去篡改异或加数的生成法则：至此，失去篡改算法。 硬盘数据复原过程：1、基于后面失去的算法，北亚企安数据恢复工程师通过Visual Studio编写修复程序。2、应用程序对F分区中的数据进行修复。修复实现后随机抽检修复好的文件，无报错。为进一步确定复原进去的数据是否失常，查找出所有JPG文件，显示缩略图，没有发现异常。3、查找所有doc文件，显示作者、题目，未发现异常。4、交由用户方进行检测，用户方让让各部门抽调员工对复原进去的数据进行检测，没有发现问题。本次数据恢复工作实现。

服务器数据恢复环境：某品牌服务器中有4块SAS硬盘组建了一组RAID5阵列，另外1块磁盘作为热备盘应用。下层操作系统为redhat linux，部署了一个数据库是oracle的OA。 服务器故障&初检：RAID5中一块磁盘离线后热备盘未主动激活rebuild，之后另外一块磁盘离线，RAID5阵列解体。因为oracle曾经不再对服务器中部署的oa提供后续反对，用户分割咱们数据恢复核心要求复原数据和还原操作系统。将故障服务器中所有磁盘编号后取出，由硬件工程师对所有磁盘进行检测。通过检测发现热备盘基本没有启用，不存在物理故障，无显著同步体现。 服务器数据恢复&操作系统还原过程：1、将故障服务器中所有磁盘以只读形式做残缺镜像，镜像过程中发现后离线的磁盘有十几个坏扇区，其余磁盘均没有发现有坏道。镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析RAID5构造信息，获取到盘序，块大小，backward parity(Adaptec)等RAID相干信息。3、依据上一步获取到的RAID相干信息虚构重组RAID并验证数据，发现200M以上的压缩包解压无报错，确定构造正确。4、依照此RAID构造生成虚构RAID到一块单硬盘上，关上文件系统没有发现显著报错。5、失去用户受权后在原盘重建RAID（重建时曾经用全新硬盘更换发现坏道的后离线磁盘）。6、将复原好的单盘用USB形式接入故障服务器，用linux SystemRescueCd启动故障服务器，而后应用dd命令全盘回写。7、回写实现后启动操作系统，然而无奈进入零碎，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。8、狐疑此文件权限有问题，用SystemRescueCd重启后查看，此文件工夫，权限，大小均有显著谬误，显然是节点损坏导致的谬误。9、从新剖析重组数据中的根分区，定位出错的/sbin/pidof，发现错误是由后离线的那块磁盘上的坏道所引起。10、应用完整的3块盘对后离线的那块盘的损坏区域进行xor补齐。补齐后从新校验文件零碎依然呈现谬误。再次查看inode表，发现后离线磁盘损坏区域有局部节点体现异样。尽管节点中形容的uid失常存在，但属性，大小和最后的调配块都是谬误的。依照所有可能进行剖析，然而没有找到办法找回此损坏节点。只能试图修复此节点或复制一个雷同的文件过去。11、针对所有可能存在谬误的文件，北亚企安数据恢复工程师通过日志确定原节点块的节点信息，而后做修改。12、修改后从新dd根分区，执行fsck -fn /dev/sda5仍然报错。依据报错信息，北亚企安数据恢复工程师在零碎中发现有多个节点共用同样的数据块。按此提醒剖析底层，发现存在节点信息的新旧交加。13、依照节点所属的文件进行辨别，革除谬误节点后再次执行fsck -fn /dev/sda5，仍然有大量报错。依据报错信息，发现这些节点多位于doc目录下，不影响系统启动，于是间接执行fsck -fy /dev/sda5强行修复。14、修复实现后重启零碎，胜利进入零碎桌面。15、启动oracle数据库服务，启动OA，一切正常无报错。16、由用户方对复原的操作系统和数据（OA和oracle数据库）进行检测，通过用户方多方检测，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：从物理机迁徙一台虚拟机到ESXI，迁徙后做了一个快照。该虚拟机上部署了一个SQLServer数据库，寄存了5年左右的数据。ESXI上有数十台虚拟机，EXSI连贯了一台EVA存储，所有的虚拟机都在EVA存储上。 服务器故障：因为工作人员的误操作，不小心将几年前迁徙数据后做的快照还原了。因为快照是几年前做的，还原快照意味着这几年的数据被删除了。还原快照相当于删除数据，底层的空间会被开释。为了防止这部分开释的空间写入新数据，须要将连贯这台存储的所有虚拟机都关掉。如果有重要的虚拟机不能长时间宕机，则须要将该虚拟机迁徙到别的EXSI上。刚好用户有一台虚拟机很重要，不能长时间关机，只能做热迁徙。vmware的热迁徙须要建设N多个快照来实现，这给前期的复原工作带来很多麻烦。 服务器数据恢复过程：Vmware的文件系统叫做Vmfs，所有的虚拟机都寄存在这个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、将故障服务器中所有磁盘编号后取出，以只读形式将所有磁盘做全盘镜像备份，备份实现后依照编号将磁盘还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析Vmfs，北亚企安数据恢复工程师编写小程序提取整个vmfs中闲暇的MAP。3、在提取出的闲暇MAP中找到一个合乎快照文件头构造的MAP。依据快照文件的构造，北亚企安数据恢复工程师调整程序提取快照文件剩下的碎片。4、快照文件提取实现后，将快照文件和原vmdk合并生成新的vmdk，新的vmdk中蕴含了所有的数据。5、挂载新的vmdk并解释其中的数据。6、用户对复原进去的数据进行验证，通过重复验证确认复原进去的数据残缺可用。本次数据恢复工作实现。

服务器数据恢复环境：一台存储设备中有一组由12块硬盘组建的RAID6磁盘阵列，下层采纳EXT3文件系统，共划分3个LUN。 服务器故障&剖析：存储设备在运行过程中RAID6阵列忽然不可用，管理员对故障存储进行了重新分配RAID的操作并进行了初始化。初始化一段时间后，管理员觉察有异，于是强行终止初始化。因为初始化过程曾经超过50%，局部数据已蒙受不可逆毁坏。RAID解体后管理员应用原RAID6阵列中的11块硬盘进行重调配RAID5，并进行了长时间的初始化，这些操作对原始数据造成不可逆的毁坏。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，以只读形式做全盘镜像备份，备份实现后将所有磁盘依照编号还原到原存储中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析原12盘RAID6的RAID和磁盘的组织构造。3、基于镜像文件剖析重新分配的11盘RAID5的RAID和磁盘的组织构造。4、基于上述剖析的RAID相干信息制订复原算法。5、依据算法，北亚企安数据恢复工程师编写&校对程序对失落的数据进行复原及修复。 6、复原实现后由用户对数据进行测验，测验没有问题后帮忙用户将数据迁徙到筹备好的环境中。

服务器数据恢复环境：一台IBM X系列服务器，4块SAS硬盘组建一组RAID5阵列，采纳的reiserfs文件系统。服务器操作系统分区构造：boot分区+LVM卷+swap分区（依照前后程序）。LVM卷中间接划分了一个reiserfs文件系统，作为根分区。 服务器故障：服务器在运行过程中因为未知起因瘫痪，管理员将服务器重装系统，重装系统后发现分区构造变为：boot+swap分区+LVM卷（依照前后程序），LVM卷中的reiserfs文件系统地位有一个空的reiserfs超级块。用户须要恢复原LVM卷中的所有用户数据，包含数据库、网站程序与网页、单位OA零碎里的所有办公文档。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，以只读形式将所有磁盘进行全盘的镜像备份。备份实现后依照编号将所有磁盘还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、北亚企安数据恢复工程师试图通过全盘reiserfs树节点之间的关联确定原reiserfs分区地位。基于镜像文件进行剖析后，发现原来存储数据的reiserfs文件系统的前2G数据被笼罩。通过和管理员的沟通，确定了故障产生过程：管理员重新安装零碎时谬误地初始化了分区构造，装好零碎后无奈导入LVM卷，于是试图通过reiserfsck进行修复。reiserfs将文件系统中所有的文件(含目录)线性化后，再以文件key生成B+树。因为树会一直减少节点，树的构造整体拉展后向整个磁盘的数据区做平滑迁徙，所以顶级节点通常不会放在文件系统的最后面。因为根目录的文件KEY号通常是最小的，所以前2G数据应该是从根起始门路最近的key节点。用户数据目录档次较深，节点存在的可能性很高。因为reiserfs文件系统后面对整个树的索引全失落，加上reiserfs的树概念设计形象，重搭建树会很艰难。3、通过北亚企安自主开发程序在扫描整个原reiserfs文件系统区域的key节点并将所有key节点导出。4、而后应用北亚企安自主开发程序将所有的叶节点从新排序、过滤(去掉之前删除文件抛弃的节点)，从新生成二级、三级、四级等叶节点。5、抉择分区后面的2G空间作为新树的构造区，生成对应地址信息。目录命名问题解决办法：针对原树门路某节点失落的状况，应用自定义的key节点编号命名；针对无奈确定其父目录，可暂退出到/otherfiles目录下。生成树索引信息并写入到特定地位，再依据这些信息生成超级块并设置clear标记。6、在suse虚拟机下创立快照，挂载修复好的卷，曾经能够看到文件了。在修复用的suse虚拟机下挂载用于拷贝数据的指标硬盘，mkfs后将所有数据cp到指标硬盘。7、用户通过find命令整顿所需数据，修改局部目录文件地位与名称。按大小与文件头标记查找局部失落的散文件，找到后挪动到对应的目录并重命名。8、通过一番致力，所有须要复原的数据都被找到了。通过用户方的检测，确认复原进去的数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：服务器中有一组由6块磁盘组建的RAID6磁盘阵列。服务器作为WEB服务器应用，下面运行了MYSQL数据库以及寄存了网站代码和其余数据文件。 服务器故障：在服务器运行过程中该raid6阵列中有两块磁盘先后离线，然而管理员没有留神到这个问题，没有及时更换磁盘。当该raid6阵列中的第三块磁盘离线时该raid6阵列解体，服务器中的数据全副失落。用户方在故障产生后立刻让当地数据恢复服务商复原数据。通过该数据恢复服务商的操作后，仍有近一个月的数据没有复原进去，MYSQL数据库重大损坏。 服务器数据恢复过程：1、将故障服务器raid6磁盘阵列中的6块磁盘以只读形式全盘镜像备份到北亚企安数据恢复核心的存储池中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后将所有磁盘依照原样还原到故障服务器中。2、基于镜像文件剖析后。发现最先离线的两块离线磁盘其实很早就曾经离线，很长一段时间曾经没有写入新的数据了。3、基于镜像文件对底层数据进行剖析，发现故障RAID6阵列采纳的是双校验：第一个校验是由一般的XOR运算生成，而第二个校验是由Reed-Solomon算法生成。4、故障服务器RAID6阵列中两块早离线的磁盘曾经很长一段时间不写入新数据了，所以要想残缺复原数据就必须使用第二个由Reed-Solomon算法生成的校验，否则会导致最新的数据失落。过后行业中还没有现成的数据恢复类软件能解决这个问题，尽管有局部软件设计了这一性能，但只是陈设而已。这也就是之前这家数据恢复服务商没可能残缺复原所有数据的起因所在。5、北亚企安数据恢复工程师剖析出原RAID6的构造等相干参数，应用北亚企安自主编写的RAID6复原软件生成出一个残缺镜像。将生成的镜像导回用户方用新磁盘搭建好的服务器环境中，开机一切正常。6、通过用户方的多方面重复验证，确认复原进去的数据残缺无效，没有任何问题。本次数据恢复工作实现。

服务器数据恢复环境：一台服务器装置的ESXi虚拟化零碎，该虚拟化零碎连贯了多个LUN，其中一个LUN上运行了数台虚拟机，虚拟机装置Windows Server操作系统。 服务器故障&剖析：管理员因误操作删除了一台虚拟机，该虚拟机上部署SQL Server数据库和寄存了一些其它格局的文件。用户方要求复原此虚拟机上所有文件，并且让该虚拟机能失常启动和工作。 服务器数据恢复过程：1、将故障服务器中的所有磁盘编号后取出，通过硬件工程师检测没有发现有硬盘存在物理故障以及大量坏道。将所有磁盘以只读形式做全盘镜像备份，备份实现后依照编号将磁盘还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、应用北亚企安自主开发的Frombyte Recovery For ESXi程序扫描镜像文件。Frombyte Recovery For ESXi程序扫描出所有的虚构磁盘，显示原虚构磁盘的大小、操作系统类型、模式（厚/薄）以及调配状态等信息。扫描进去的虚构磁盘：3、扫描进去的虚构磁盘中有两个虚构磁盘的调配状态为“NO”，意味着这两个虚构磁盘就是管理员删除的虚拟机中的虚构磁盘。 4、应用Frombyte Recovery For ESXi复原出这两个虚构磁盘，而后导入到本地的ESXi服务器上。北亚企安数据恢复工程师将导入的虚构磁盘加载到虚拟机上，虚拟机能够失常启动。在本地ESXi上启动的的虚拟机：5、通过用户对虚拟机以及其中的数据进行检测后，确认复原进去的数据残缺无效。本次数据恢复工作实现。

EVA系列存储是一款以虚拟化存储为实现目标的中高端存储设备。EVA存储中的数据在EVA存储设备工作过程中会一直进行迁徙，如果运行的工作比较复杂，EVA存储磁盘负载减轻，很容易呈现故障的。EVA存储通过大量磁盘的冗余空间和故障后rss冗余磁盘动静迁徙来爱护存储中的数据安全，但如果掉线磁盘越来越多，这种爱护数据安全的能力会超过阈值，直至存储解体。上面分享一个EVA存储的数据恢复案例。 EVA存储故障&检测：硬件架构：EVA某型号控制器+EVA扩大柜+若干FC磁盘。磁盘故障导致EVA存储中的LUN不可用，下层利用无奈失常应用。北亚企安数据恢复工程师拿到故障存储后，将所有磁盘编号后取出，对所有磁盘做物理故障检测，通过检测发现所有磁盘不存在物理故障，也没有在磁盘中发现大量的坏道。将所有磁盘以只读形式做全盘镜像备份，镜像实现后依照编号将所有磁盘还原到原存储设备中，后续的数据分析和数据恢复操作在镜像文件上进行，防止对原始磁盘数据造成二次毁坏。 EVA存储故障剖析：磁盘没有发现物理故障或者大量坏道，服务器数据恢复工程师初步判断故障的起因是某些磁盘读写不稳固。EVA控制器针对磁盘的检测策略十分严格，EVA控制器通常状况下会认定性能不稳固商务磁盘为坏盘并踢出磁盘组。一旦某个LUN的同一个条带中掉线的盘达到极限，这个LUN将不可用。也就是说如果EVA中所有的LUN都蕴含这些掉线的盘，这些LUN都会受影响。所以局部磁盘故障掉线也可能会导致存储无奈失常应用。EVA存储中的LUN是以RAID条目标模式来存储数据的。EVA存储将每个磁盘的不同块组成一个RAID条目，RAID条目有数种类型。如果要复原数据就须要剖析出组成LUN的RAID条目类型以及RAID条目是由哪些盘的哪些块组成的。这些信息都寄存在LUN_MAP中，每个LUN都有一份LUN_MAP。EVA将LUN_MAP别离寄存在不同的磁盘中并应用一个索引来指定其地位。因而在磁盘中找到这个指向LUN_MAP的索引就能够找到现存LUN的信息了。因为EVA存储中掉线的磁盘存在古老的数据，在复原数据的时候须要将这些磁盘都排除掉。因为LUN中的阵列是RAID5，将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值作比拟就能够判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就能够晓得这个LUN中哪些RAID条目中有掉线硬盘。这些RAID条目中都存在的那个盘就肯定是掉线盘。排除掉线盘后通过LUN_MAP复原出所有LUN数据即可。 EVA存储数据恢复过程：1、北亚企安数据恢复工程师编写扫描LUN_MAP的程序扫描全副LUN_MAP，而后通过人工剖析确定LUN_MAP。2、编写检测RAID条目标程序检测所有LUN中掉线的磁盘，而后通过人工剖析排除掉线的磁盘。3、编写LUN数据恢复程序，联合LUN_MAP复原所有LUN数据。人工核查每个LUN，确认是否和用户方形容的统一。局部LUN的数据：4、剖析复原进去的LUN，重组&解析ASM磁盘组。剖析每个LUN前端的构造数据，依据ASM磁盘头构造来辨别哪些LUN是属于ASM磁盘组的。通过剖析共发现有2套ASM磁盘组。每个ASM磁盘组蕴含的LUN中的分区状况如下：应用ASM构造解析工具解析和修复ASM磁盘组，解析出此ASM中存储的所有数据库文件。将解析进去的数据库文件依照文件类型分组导出并对导出数据进行检测。应用ASM解析工具复原出所有的数据库文件。5、依据用户方的形容，所有LUN的数据分成两大部分：Vmware的虚拟机和ORACLE上的ASM磁盘组数据。ASM磁盘组中寄存的是Oracle的dbf数据库文件。因为通过复原进去的LUN无奈间接看到外面的文件，人工核查哪些LUN寄存Vmware的数据，哪些LUN寄存ASM设施，而后将LUN挂载到不同的验证环境中验证复原的数据的完整性（验证过程就不赘述了）。6、验证没有问题后，将vmware虚拟机文件和Oracle数据库文件移交给用户方。用户方将移交的数据上传至后盾，程序可失常运行，没有发现问题，用户认可复原后果。运行状况如下。 运行规定： 运行变更摘要：

服务器数据恢复环境：某单位有一台HP EVA存储，连贯2组扩大柜，扩大柜中有12块FATA磁盘和10块FC磁盘，不确定数量的LUN，主机装置WINDOWS SERVER操作系统，存储设备用来寄存该单位的重要材料。 服务器故障初检：存储不可用。因故障存储在多家数据恢复服务商解决过，所以在临时无奈间接定位故障起因。将EVA主机及扩大柜关机，将所有硬盘标好地位序号后取出。将所有磁盘连贯到北亚企安数据恢复平台上。磁盘连贯如下图：进入零碎后用工具查看磁盘状况，所有磁盘均可失常辨认。查看每个磁盘信息，发现FC磁盘PV HEAD还在，而在FATA磁盘上没有找到PV HEAD。查看FC磁盘中存储的Metadata，发现仅形容了一个RSS组成的LUN，成员盘为所有的FC磁盘。而FATA磁盘中残留的LUN至多包含数组信息。这种状况象征FATA磁盘组成的DISK GROUP中所划分的所有VDISK被删除，并且所有FATA磁盘被UNGROUP。 服务器数据恢复过程：1、将故障存储中所有磁盘以只读形式做残缺镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后依照编号的编号将所有磁盘还原到原存储中。2、应用Frombyte recovery for HP-EVA复原FC磁盘所属的LUN。3、因FATA磁盘已全副被UNGROUP，对于RSS的调配和磁盘ID均无奈获知。北亚企安数据恢复工程师通过人工形式剖析RSS配置表。通过对照META信息和通过xor信息区的校验验证，失去rss组配置表：3-0  hd63-1  hd83-2  hd23-3  hd93-4  hd103-5  hd52-0  hd02-1  hd72-2  hd12-3  hd112-4  hd32-5  hd44、北亚企安数据恢复工程师将所有LUN的存储调配表进行重组及整合。5、依据存储调配表和RSS磁盘调配表提取所有LUN。提取过程中人工剖析不通过的XOR条带，找到最佳重组论断，而后通过Frombyte recovery for HP-EVA进行复原。

EVA存储原理：EVA系列存储是以虚拟化存储为实现目标的中高端存储设备，外部的构造组成齐全不同于其余的存储设备，RAID在EVA外部称之为VRAID。EVA会在每个物理磁盘（PV）的0扇区写入签名，签名后PV会被调配到不同的DISK GROUP。在DISK GROUP中每个PV会按肯定大小划分为若干存储单元（PP），PP的大小为2的整数次幂，大小在2-16M之间。每个PV中有无限数量的PP，这些PP组成了DISK GROUP的可用空间。每5-15个PV组成一组RSS，每个RSS相当于一个惯例RAID的冗余组，但这个冗余组不等同于惯例RAID。与惯例RAID类似的是，惯例RAID是以磁盘为单位的RAID算法，而RSS是基于PP的RAID算法。为进步性能，HP EVA会有偏向地轮流调配不同的RSS组，但这些RSS之间的数据存储是基于JBOD的，每个RSS组成的stripe的成员其实是不同PV中不同地位的PP。无论RSS中成员数量有多少个，对于VRAID5，一个stripe中的PV数总是5个。对于VRAID6，一个stripe中的PV数总是6个。例如，对于VRAID5，EVA会尽可能在N个磁盘中做C(N,5)的组合状况来实现IO负载平衡。当一个RSS中某个PV离线，控制器会从同一个RSS组中其余磁盘中寻找可用的PP，在逻辑上实现每个stripe的rebuild，从而保障整个存储的安全性。当一个RSS中磁盘数量足够少时，这个RSS的安全性就非常低了，这时候，EVA会合并此RSS到另一个RSS中，这样可用的冗余空间就是共享的了，空间就能够从另一个较平安的RSS中迁徙过去。为了保障有足够的空间提供冗余爱护，在创立DISK GROUP时，EVA会提供一个Protection Level，single示意用2个磁盘的空间做冗余，double示意用4个磁盘的空间做冗余。但这个冗余不同于hotspare，这个冗余空间仅会预留到每个PV的尾部。 EVA存储常见故障：1、RSS中多个磁盘掉线，超过冗余爱护级别。2、退出新磁盘进行数据迁徙时，新磁盘存在物理故障。3、VDISK删除或EVA initialize。4、主机与存储突发性的无奈连贯，无奈discover存储。 EVA存储数据恢复原理：EVA系列存储最外围的构造局部来自于所有vdisk的运算pp map，这个pp map会因为磁盘的一直迁徙而迁徙，所有的故障均可基于此pp map复原。当pp map不存在时，依据不同的条带之间的冗余关系，通过优化算法对所有PP进行条带性汇合，造成若干组正确的条带数据。再基于文件系统构造、数据结构等特色重组条带。 EVA存储数据恢复流程：1、将EVA主机一端的连线插入，间接连入主机hba卡上，就能够辨认出所有的物理硬盘，而后将所有磁盘做镜像。因为EVA主机与扩大柜多是应用铜线连贯，因而可能须要在扩大柜上减少光纤收发模块，再通过光链路连贯fc hba卡。当然，也能够把所有硬盘拆下放入其余光纤通道柜中进行镜像。应用EVA扩大柜进行镜像：2、通过北亚企安自主开发的frombyte recovery for hp eva程序进行vdisk重组，间接写入成镜像文件或指标物理磁盘。3、解释镜像文件或指标磁盘，迁徙镜像或导出外部文件。

服务器数据恢复环境：一台HP ProLiant DL系列某型号服务器，hp smart array控制器，挂载了一台国产磁盘阵列，磁盘阵列中是一组由十几块SCSI硬盘组建的RAID5，RAID中的冗余采纳双循环的校验形式。服务器操作系统为LINUX，下层搭建了NFS+FTP，服务器作为公司外部文件服务器应用。 服务器故障&检测：机房搬迁后在新机房连贯好各种线路，服务器开机后无奈辨认RAID，提醒未做初始化。北亚企安数据恢复工程师对故障服务器和磁盘阵列进行初检，发现服务器产生故障的起因是raid信息失落。 服务器数据恢复过程：1、将SCSI磁盘柜连贯到不蕴含RAID性能的SCSI扩展卡，而后在数据恢复平台上以单盘的形式连贯故障服务器磁盘阵列中的所有磁盘。2、将故障服务器存储中的所有硬盘以只读形式做残缺镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。3、基于镜像文件剖析原RAID5的双循环校验参数，依据剖析获取到的raid相干信息从新搭建虚构raid。4、在虚构RAID中踢掉早离线的盘并应用北亚企安自研文件系统解释程序解释文件系统，解释完文件系统后就能够导出raid数据。5、在原服务器上连贯磁盘阵列，重新配置RAID。6、最初通过网络dd、NFS、SAMBA、FTP、SSH等数据传输办法把所有数据传回原服务器新搭建的raid磁盘阵列中。7、用户方工程师通过重复验证，确认复原数据残缺无效。本次数据恢复工作实现。

HP-LeftHand存储简介：HP LeftHand存储反对RAID5、RAID6、RAID10磁盘阵列，反对卷快照，卷动静扩容等。服务端：客户端：LeftHand存储分为三个层级：物理磁盘、逻辑磁盘、逻辑卷。多个物理磁盘组成一个逻辑的磁盘，也就是RAID磁盘阵列；将不同RAID磁盘阵列组成一个空间，将空间中不同的区域划分为一个一个的卷。 卷由不同RAID阵列的N个不间断的片段组成，是用户的可用空间，寄存文件系统以及用户的数据，RAID后面一部分空间用来存储记录这些片段的MAP。RAID是LeftHand存储能辨认的最小单元，LeftHand存储应用比拟多的是RAID5或RAID6。物理磁盘中寄存的数据是不间断的，如果组建的是RAID5或RAID6，那么物理磁盘中还寄存有校验数据。 HP-LeftHand存储故障：某法院的一台LeftHand存储因raid磁盘故障导致存储不可用，更换磁盘强制上线后存储依然不可用。存储构造： HP-LeftHand存储数据恢复过程：1、由硬件工程师先对故障存储中的所有硬盘做检测，所有磁盘均可失常读取，没有发现存在物理故障。2、将所有磁盘以只读形式做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。3、基于镜像文件剖析底层数据。故障存储中有2组RAID5：第一组是HP双循环RAID5，该RAID失常；第二组也是RAID5，呈现问题的就是第二次RAID5。依据RAID5的特点，第二组RAID中掉盘数量至多为2块。4、北亚企安数据恢复工程师通过穷举+校验的办法剖析找出第二组RAID中早掉线的那块磁盘并踢出，依据剖析获取到的RAID相干信息重组RAID。注：穷举法：假如其中一块磁盘是早掉线的，踢掉此盘，重组RAID而后生成全副数据，将数据挂载到环境中看数据是否正确。如果数据不正确，那么再假如另一块盘是早掉线的，以此循环。尽管这种计划可行，然而每次重组RAID生成数据耗时较长且准确率低。穷举+校验法：和穷举法一样，假如某个磁盘是早掉线的，踢掉磁盘后重组RAID，但不生成全副的数据，而是只生成后面几个G的数据，因为HP-LeftHand存储的数据的索引表位图位于RAID的前几个G的数据范畴。只有通过查看这个索引表位图的信息是否正确就能够判断此RAID是否正确。如果正确就生成此RAID的全副数据。5、将生成的数据和第一组完整的RAID一起挂载到故障存储上，启动存储，下层卷可用，查看最新文件没有发现问题。交由用户方检测，用户方工程师通过重复认证检测，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：曙光某型号光纤存储柜，16块光纤磁盘组建了2组RAID5磁盘阵列，每组raid5阵列中有7块成员盘，另外2块磁盘配置为全局热备盘应用。第一组RAID5阵列划分了3个LUN：1个LUN调配给linux主机、第2个LUN调配给sun小型机，第3个LUN调配给esxi主机。第二组RAID5阵列全副调配给一台ESXI主机，运行10台虚拟机。 服务器故障&剖析：存储中磁盘报警，存储原厂技术人员对raid5磁盘阵列进行了更换磁盘的操作，更换实现后对存储进行了优化。在优化存储的过程中原厂技术人员删除了所有的VG，而后将备份信息导入，后果第二组RAID5阵列被ESXi主机辨认后提醒须要初始化。呈现故障的raid5阵列在更换磁盘后会马上进行数据同步，如果此时删除VG信息，数据同步就会停止。将备份的VG信息导入后，RAID就是一个新的RAID阵列，数据一旦同步则新的raid阵列将同步为空白磁盘，数据不可复原。所幸技术人员为了平安起见，敞开了数据同步性能，否则服务器的数据将蒙受不可逆的毁坏。 服务器数据恢复过程：1、将故障存储中所有磁盘以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作将基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析raid构造，依据剖析获取到的raid相干信息虚构重构RAID。3、重构实现后将RAID镜像到筹备好的存储中，通过北亚企安数据恢复核心自主研发的数据恢复软件能够看到所有的数据。4、将复原好的存储挂到提前准备好的ESXi服务器上，让用户方进行验证，所有虚拟机都能够失常启动。对虚拟机中的数据进行查看也没有发现问题。用户确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：一台IBM某型号服务器，4块SAS磁盘组建了一组RAID5磁盘阵列。服务器装置的windows server操作系统，下面运行了一个Oracle单节点，数据存储为文件系统，无归档。该oracle数据库的数据量不大，只有一个用户，应用默认的users表空间，users空间下只有一个不大的数据文件。 服务器故障：因为服务器超负荷运行，RAID5磁盘阵列呈现问题。为了保障服务器能失常稳固运行，工作人员做了重建RAID的操作，在重建RAID过程中因为RAID中的一块磁盘呈现故障，RAID初始化停止，大量数据被同步而毁坏，然而RAID5磁盘阵列曾经能够拜访。服务器操作系统尽管呈现谬误，但还能失常启动。oracle数据库所在D盘分区报错无奈关上，工作人员做了chkdsk后能失常关上D盘分区，但oracle数据库无奈启动。工作人员在D盘上重装了oracle数据库并导入了以前备份的dmp文件，但数据和出故障前的oracle数据库数据相差太多。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析RAID。因为重建RAID会给数据造成重大的毁坏，但通过对底层数据的剖析发现重建的RAID的块大小、盘序都和原来的RAID统一。在初始化过程中仅同步了后面局部的大量数据，RAID数据损坏不大，数据库还没被毁坏。3、Chkdsk并不会毁坏用户数据区，chkdsk只对文件系统元数据区进行批改。执行chkdsk操作后oracle数据库文件没有被毁坏，最多只是文件的MFT或目录项被毁坏。真正对数据毁坏重大的操作是重装Oracle数据库和导入dmp文件，这一系列操作不仅对文件系统元数据区造成了毁坏，还将用户数据区进行了笼罩。4、基于镜像文件剖析D盘的NTFS文件系统，发现所有原oracle数据文件的MFT均被笼罩，NTFS日志也被轮回笼罩，从NTFS元数据区找不到可利用信息。数据恢复工程师只能应用北亚企安自主研发的Oracle恢复程序对整个D盘分区进行复原。5、通过程序的扫描，发现Oracle实例为ANSORA，扫描出一个原始残缺的管制文件和一个原始残缺的undotbs表空间数据文件。重要的system和users表空间数据文件都被不同水平的毁坏：其中system表空间的数据文件仅剩中后部的十多MB，原始文件应该约有几百MB；users表空间的数据文件有局部被笼罩，仅剩几MB。提取出找到的数据，而后对损坏重大的数据库进行修复。6、因为system表空间不可用，无奈失去数据字典。通过沟通，用户方确认了有重要的三张表，从imp回去的数据库中获取到这三张表的构造，再从复原users表空间的数据文件中找到对应的segment。但有一张表无奈对应上，再次沟通得悉这一张表有过更改字段的操作，北亚企安数据恢复工程师只能从新构建新的表构造对应上users表空间数据文件中segment，而后通过dul工具提取这三张表的数据。7、提取实现数据后由用户方工程师进行验证，通过重复验证，用户方工程师确认复原进去的数据无效。本次数据恢复工作实现。

服务器数据恢复环境：DELL PowerVault系列某型号存储，15块硬盘搭建了一组RAID5磁盘阵列。 服务器故障&检测：存储设备raid5阵列中一块磁盘因为未知起因离线，管理员对该磁盘阵列进行了同步操作。在同步的过程中又有一块磁盘指示灯报警，磁盘离线，磁盘阵列同步失败，raid5阵列解体，存储无奈失常工作。北亚企安数据恢复工程师对故障存储中的物理磁盘状态进行了检测，通过检测发现该raid5磁盘阵列中先离线的硬盘访问速度极为迟缓，第二块离线的磁盘有大量坏扇区，其余磁盘无显著物理故障。该raid5磁盘阵列只蕴含一个卷组，该卷组占用阵列全副空间，该卷组只有一个起始地位为0扇区的XFS裸分区。RAID5阵列只反对一块磁盘的谬误冗余性能，当第二块磁盘离线后阵列便无奈失常工作，所以整个阵列的解体次要是因为第二块磁盘的离线造成的。第二块磁盘是否能解决好是数据恢复的要害。 服务器数据恢复过程：1、对故障存储中15块硬盘进行异或测试，所有磁盘全副通过测试，没有发现显著谬误。2、以只读形式镜像备份所有完整的磁盘数据，后续的数据分析和数据恢复操作都基于镜像文件进行，防止在数据恢复过程中对原始磁盘数据造成二次毁坏。3、对第二块离线的硬盘进行独自备份，备份过程中略过坏扇区。计算第二块硬盘损坏扇区地位的数据，并将其写入镜像文件。4、基于镜像文件剖析原RAID5阵列构造信息，依据剖析获取到的raid相干信息构建RAID5阵列。5、重构RAID后验证RAID构造是否正确。6、将第二块磁盘的镜像备份到新硬盘，并将其强制上线。更换第一块磁盘并对其进行同步。7、实现上述操作后，由用户方工程师亲自对复原进去的数据进行检测，通过重复检测，用户方确认复原进去的数据残缺无效。 服务器数据恢复总结：因为故障存储中所有硬盘的异或测试全副通过，这意味着存储产生故障后没有新数据的写入或者构造的改变。在这种状况下能够依据其余几块完整的硬盘计算出坏硬盘对应地位的数据。复原实现后进行查看，目录构造残缺，重要文档完整，FSCK无任何谬误提醒，用户认可所复原的数据。

服务器数据恢复环境：IBM某型号服务器，服务器中5块SAS磁盘组建了一组RAID5磁盘阵列。划分了一个LUN以及3个分区：第一个分区寄存windows server零碎，第二个分区寄存SQL Server数据库，第三个分区寄存备份文件。 服务器故障：服务器在运行过程中解体，raid阵列不可用。北亚企安数据恢复工程师对故障服务器中的raid5磁盘阵列进行初检，发现故障服务器raid5中的2块磁盘离线，通过检测均存在物理故障。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，连贯到北亚企安备份服务器，以只读形式对所有磁盘做全盘镜像备份（有物理故障的先修复物理故障而后应用业余工具进行备份，完整的磁盘失常备份即可），备份实现后将所有磁盘依照编号还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析磁盘在RAID5阵列中的相干参数。在剖析过程中发现阵列中的离线的磁盘中的一块损坏重大，离线工夫较早，没有在其中找到新的数据，这块磁盘没有修复的必要性。所以要想复原数据，后掉线的那块磁盘就必须修复好。3、硬件工程师将阵列中后掉线的磁盘修复好后，北亚企安数据恢复工程师依据后面剖析出的原RAID5相干参数虚构重构RAID。RAID重构实现后，原服务器上的三个分区均可失常拜访，并且能看见所有的文件。4、将重要的SQL SERVER数据库文件复原进去，而后将复原进去的数据库文件附加到筹备好的SQL SERVER数据库上进行验证和查看，没有发现异常状况。由用户方工程师对数据库进行检测，通过重复认真检测后，确认复原进去的数据残缺无效。本次数据恢复工作实现。

服务器故障：一台IBM V7000存储中的vdisk失落，Solaris操作系统中的部署的Oracle数据库不可用。通过和工作人员的沟通得悉故障起因：工作人员进行重建MDisk的操作，将原先的raid10重建为raid6，而后又再次重建为raid10，这一系列操作导致存储池中的VDisk失落，导致下层Solaris操作系统中的Oracle数据库不可用。用户须要复原Oracle数据库数据。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，以只读模式连贯到北亚企安备份服务器上做全盘镜像备份。备份实现后依照编号将所有磁盘还原到原存储中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析磁盘底层数据，评估Mdisk重建操作对数据的毁坏水平。3、剖析重建后的raid6的数据分布规定，计算出RAID6的双校验写到硬盘的具体位置。因为raid6的双校验会毁坏数据区域，针对此数据区域北亚企安数据恢复工程师联合raid10的散布规定尽可能的去还原原来的Mdisk。4、对复原进去的Mdisk进行底层卷剖析，取出精简模式的数据MAP，校验数据MAP是否失常。联合精简模式的算法和数据MAP去还原VDisk。5、VDisk的数据恢复实现后，联合未损坏的VDisk扫描Oracle数据库页特色并生成相应的数据库文件的特色集。6、剖析出Oracle数据库在所有VDisk中的数据分布MAP并复原数据库文件。复原实现后应用北亚企安自研软件对数据库文件做一致性检测，检测后果是所有数据库文件失常、构造残缺。7、尝试启动数据库实例，状态一切正常。导出数据库，交由用户方工程师进行检测，通过重复检测后确认确认数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：一台ibm某型号服务器，5块硬盘组建一组raid5磁盘阵列，redhat linux操作系统，下层部署有oracle数据库。 服务器故障：raid5阵列中两块硬盘离线，服务器解体。通过初检发现故障服务器中的硬盘不存在物理故障，热备盘未激活，无同步迹象。 服务器数据恢复过程：1、将故障服务器中的所有磁盘编号后取出槽位，挂载至北亚企安数据备份平台，以只读形式做全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘造成二次毁坏。备份实现后将磁盘依照编号还原到原服务器中。对硬盘做镜像过程中，发现除了2号盘有十几个坏扇区外，其余硬盘均失常。2、基于镜像文件剖析raid5构造，获取到原阵列中的条带大小、校验方向、条带规定以及meta区域等raid相干信息。3、依据剖析进去的raid相干信息虚构重构raid5。重构实现后进行数据验证，200M以上的最新压缩包解压无报错。将raid5生成到一块硬盘上，通过USB的形式接入到原服务器，而后通过linux SystemRescueCd启动故障服务器并应用dd命令进行全盘回写。4、数据回写实现后无奈进入操作系统，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。北亚企安数据恢复工程师应用SystemRescueCd重启后进行查看，发现文件的权限、工夫、大小都有显著谬误。对根分区再次进行剖析，定位出错的/sbin/pidof/，确定呈现谬误的起因是2号盘有坏道。5、通过其余盘针对2号盘的损坏区域进行xor补齐并从新校验文件零碎，仍然出错。数据恢复工程师只好再次查看inode表，发现2号盘损坏区域有局部节点体现为（图中的55 55 55局部）： 6、尽管节点中形容的uid还在，但大小、属性和最后调配块全副是谬误的。通过日志确定原节点块的节点信息并进行修改，从新dd根分区，执行“fsck -fn /dev/sda5/”命令进行检测。报错状况如下图： 7、通过剖析发现，原来3号盘最先离线，节点信息新旧交加导致有多个节点共用数据块。北亚企安数据恢复工程师按节点所属的文件进行区别，革除谬误节点后再次执行“fsck -fn /dev/sda5”命令，仍然有局部位于doc目录下的节点报错。因为不影响启动，强行修复后重启零碎，零碎失常，启动数据库失常。8、通过用户方工程师重复验证，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：某公司一台EMC某型号存储中有一组由12块硬盘组建的raid5磁盘阵列，其中有2块盘作为热备盘应用。 服务器故障&剖析：raid5磁盘阵列中有2块磁盘离线，只有1块热备盘胜利启用，另外一块热备盘未启用，raid阵列解体。服务器硬盘离线的起因无非为磁盘呈现物理故障或者硬盘呈现坏道。因为EMC的raid控制器磁盘查看策略比拟严格，常常将阵列中性能不稳固的磁盘断定为物理故障并踢出阵列。所以导致EMC存储中磁盘阵列解体的起因有可能是因为磁盘读写不稳固。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，由硬件工程师对所有磁盘做物理故障检测，通过检测发现没有磁盘存在物理故障和坏道。以只读形式将所有磁盘做全盘镜像备份，备份实现后将所有磁盘依照编号还原到原存储中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 2、基于镜像文件剖析原RAID5磁盘阵列构造，通过剖析发现2块热备盘上没有数据，其中一块热备盘已胜利激活并替换了其中的一块离线磁盘，但数据并未同步。持续剖析条带大小、数据的散布法则、磁盘程序等raid相干信息，发现有一块盘在同一条带上的数据与raid中其余硬盘不同，初步判断该盘为掉线较早的硬盘。应用北亚企安自主开发的raid校验程序对此条带进行校验，确认这块盘为先掉线的盘。通过剖析获取到的raid相干信息虚构重构原raid5磁盘阵列。 3、对磁盘阵列中的LUN信息进行剖析后解释map数据并导出。应用北亚企安自主开发程序解释zfs文件系统，某些文件系统中的文件在解析过程中报错。北亚企安数据恢复工程师手动debug程序做后发现报错的起因是ZFS文件系统在进行I/O操作时raid阵列解体导致某些元文件损坏，程序无奈失常解释。只有修复好损坏的文件系统元文件后，能力应用程序解析ZFS文件系统。 4、应用程序解析修复好的ZFS文件系统，解析所有文件节点及目录构造。通过用户方工程师的重复验证，确认复原进去的数据残缺可用。局部文件目录和验证截图：

NetApp存储故障&剖析：某公司一台NetApp存储，工作人员误操作删除一个重要的文件夹。尽管被删除曾经有一段时间了，然而依据NetApp文件系统WAFL的特点，数据被笼罩的可能性不大。 NetApp存储数据恢复过程：1、因为不同版本WAFL文件系统差距较大，所以须要先依据节点的构造判断数据块节点指针和WAFL文件系统版本。通过北亚企安数据恢复工程师对该NetApp存储的数据结构的剖析，判断该WAFL文件系统版本和数据块指针。2、北亚企安数据恢复工程师通过剖析，得悉该WAFL文件系统的blocksize（扇区数）、数据块扇区和block标记扇区等信息。块校验扇区：3、剖析目录构造。该NetApp存储的目录构造中寄存了文件、文件夹以及文件系统自身的元信息。除此之外，目录构造还寄存了文件的节点（节点惟一）和父文件夹的节点，且与数据节点中的信息统一。目录：4、将下面步骤中提到的重要信息全副通过人工剖析实现后，全盘扫描存储，将所须要的节点信息和目录信息扫描进去并存放到数据库中以备应用。5、在数据库中依据用户方的形容查找出所须要的文件夹并建设目录树，北亚企安数据恢复工程师依据NetApp存储的算法和需要编写程序，应用该程序基于建设的目录提取出户所需数据。6、提取实现后将数据交由用户方进行校检，通过用户方工程师的重复检测，确认复原数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：两组别离由4块SAS硬盘组建的raid5磁盘阵列，ext3文件系统，通过LVM治理磁盘存储。 服务器故障：一组raid5磁盘阵列中的1块硬盘故障离线，热备盘胜利启用并开始同步数据，在同步还没有实现的状况下该组raid5阵列中的另外一块硬盘故障掉线，该组Raid5阵列解体，LVM构造损坏，文件系统无奈失常应用，服务器瘫痪。工作人员对掉线的硬盘进行初检检测，先掉线的硬盘无奈辨认，后掉线的硬盘能够辨认。 服务器数据恢复过程：1、硬件工程师对无奈辨认的、先掉线的那块硬盘进行收盘检测，发现盘片磨损重大，无奈复原该盘的数据，只能依照缺盘状态进行解决。2、将故障raid5阵列和失常的raid5阵列中所有磁盘（除去最先掉线的那块磁盘）以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 3、基于镜像文件剖析原raid5磁盘阵列的校验形式、条带大小、硬盘盘序等RAID相干信息，依据剖析获取到的raid相干信息重组两组raid5阵列。 4、北亚企安数据恢复工程师基于两组重组实现的raid5阵列剖析底层数据，剖析出lvm构造信息并导出作为pv的lun。重组pv并从新生成lvm逻辑卷。 5、实现LVM重组后，解析LV（逻辑卷）中的EXT3文件系统，导出其中的全副数据。 服务器数据恢复后果：因为阵列中的先掉线的硬盘盘片划伤重大，无奈修复，且局部硬盘中存在坏道，raid构造中存在缺点，然而通过用户方工程师的重复检测，发现大部分文件复原胜利，确认本次数据恢复后果无效。

服务器数据恢复环境：Linux操作系统服务器，EXT4文件系统。服务器上部署3台KVM虚拟机： 虚拟机1：主数据库服务器虚构磁盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4数据：MySQL数据库 虚拟机2：备份数据库服务器虚构磁盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4数据：MySQL数据库 虚拟机3：代码服务器虚拟机盘：系统盘（qcow2）+数据盘（raw）文件系统：EXT4数据：程序代码 服务器故障：3台KVM虚拟机被误操作删除，须要复原raw格局的磁盘文件。 服务器数据恢复过程：1、将故障服务器中的所有磁盘编号后取出，以只读形式进行全盘镜像，镜像实现后将所有磁盘依照编号复原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析故障服务器的EXT4文件系统，定位被删除KVM虚拟机磁盘文件的节点地位。3、获取磁盘文件残留的索引信息。校验残留索引信息的正确性并修复毁坏不重大的索引。获取的索引信息： 4、修复完索引后，解析残留的各级索引并从KVM虚拟机所在的卷中提取虚构磁盘文件。5、依据虚构磁盘文件的提取状况获取卷中未被索引到的自由空间。6、校验提取出的磁盘文件的正确性与完整性。7、从自由空间中获取无效信息，北亚企安数据恢复工程师尝试修补虚构磁盘文件（如节点，目录项，数据库页等信息）。提取出的自由空间： 服务器数据恢复后果：因为局部索引失落，提取出的虚构磁盘文件不残缺。1、针对数据库文件有失落的状况，能够通过从自由空间中获取到的数据库页修补数据库文件，但局部页所在区域被笼罩，只能尽可能去补页。2、针对代码服务器中的节点和目录项失落的状况，若节点或目录项有残留，能够尝试去补齐节点和目录项。然而局部文件的节点和目录项同时失落，依据节点和目录项之间相关联的个性，这种状况下无奈补齐。因为程序代码文件不具备肯定的规律性，若其数据区失落则无奈补齐。复原出的局部目录构造： 数据验证：对虚构磁盘文件及其中的数据库文件尽力修补之后，由用户方工程师对复原进去的数据进行验证。通过重复验证，尽管有局部数据无奈复原，但重要数据都复原进去了，数据无效。本次数据恢复工作实现。

服务器数据恢复环境：一台服务器中有一组由数块SAS硬盘组建的RAID5阵列，阵列中有1块热备盘，下层部署OA以及Oracle数据库。 服务器故障：该磁盘阵列中有2块硬盘呈现故障先后离线，RAID5阵列瘫痪，下层LUN无奈失常应用。通过检测发现硬盘无物理故障，无坏道。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号后取出，以只读形式做全盘镜像，备份实现后将磁盘依照编号还原到原服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 2、基于镜像文件剖析底层数据获取RAID条带大小、磁盘程序及数据走向等RAID相干信息，依据获取到RAID信息重组RAID5。3、剖析LUN在RAID中的分配情况和LUN调配的数据块MAP。提取每一个LUN的数据块散布MAP，北亚企安数据恢复工程师编写程序解析所有LUN的数据MAP，依据数据MAP导出所有LUN的数据。 4、对导出的LUN的数据进行剖析，发现所有LUN中均蕴含HP-Unix的LVM信息。通过解析每个LUN中的LVM信息，发现共有三套LVM：一个LVM划分了一个LV来寄存OA服务器端的数据；第二个LVM中也划分了一个LV来寄存长期备份数据；剩下的4个LUN组建了一个LVM，划分了一个LV来寄存Oracle数据库文件。5、北亚企安数据恢复工程师编写程序解释每套LVM中的LV卷，但在解释的过程中程序报错。通过剖析发现报错起因是raid5瘫痪导致LVM信息损坏。人工修复损坏区域后，同步批改解释程序后胜利解释LVM逻辑卷。6、搭建HP-Unix环境，将解释进去的LV卷映射到HP-Unix并尝试挂载文件系统。然而挂载文件系统时出错，尝试应用“fsck –F vxfs” 命令修复vxfs文件系统，但修复实现后还是无奈挂载。7、剖析解释进去的LV，依据VXFS文件系统的底层构造校验此文件系统的完整性。通过剖析发现VXFS文件系统果然有问题，呈现问题的起因是：当raid5瘫痪时VXFS文件系统正在执行IO操作，导致局部文件系统元文件没有更新以及损坏。手工修复这些损坏的元文件直至可能失常解析VXFS文件系统。8、将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，这次没有报错，胜利挂载。9、在HP-Unix小机上胜利mount文件系统后，将所有用户数据均备份至指定的磁盘空间。局部文件目录截图如下： 10、应用Oracle数据库文件检测工具检测数据库文件的完整性，检测无误后应用北亚企安自主研发的Oracle数据库检测工具进行检测，通过检测发现局部数据库文件和日志文件校验不统一。数据库工程师对这部分文件进行修复后并再次校验，直至所有数据库文件均通过校验。11、将复原进去的Oracle数据库附加到原始生产环境中，尝试启动Oracle数据库，启动胜利。 数据验证：在用户方的配合下启动Oracle数据库和OA服务端。在本地电脑上装置OA客户端，通过OA客户端验证新旧数据记录，安顿不同部门人员进行近程验证。通过重复验证确认数据残缺无误。本次数据恢复工作实现。

虚拟机数据恢复环境：一台某品牌720服务器，4块STAT硬盘通过RAID卡组建raid10磁盘阵列。部署的XenServer虚拟化平台+Windows Server操作系统，共两个虚构磁盘：数据盘+系统盘。服务器作为Web服务器应用，下层部署ASP + SQL Server。 虚拟机故障&检测：机房断电导致XenServer中的一台VPS不可用，XenServer虚拟机磁盘文件失落。将故障服务器中所有磁盘编号后取出，以只读形式做全盘镜像，镜像实现后将磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。基于镜像文件剖析故障服务器中的磁盘数据，北亚企安数据恢复工程师发现故障服务器中的磁盘是通过LVM进行治理，每一个虚构磁盘为一个lv，虚构磁盘为精简模式，XenServer记录lvm的相干信息。在/etc/lvm/backup/目录下查找lvm相干信息，后果没有发现损坏的虚构磁盘信息，lvm信息应该是被更新过。所以只能通过剖析底层数据来尝试查问未被更新的lvm信息。查问后果如下： 数据恢复工程师通过查问到的未被更新的lvm信息找到虚构磁盘的数据区域，后果发现数据已被毁坏。确定虚拟机不可用的起因：虚构磁盘被毁坏，操作系统和数据失落。 虚拟机数据恢复过程：通过北亚企安数据恢复工程师团队通过会诊后，敲定了2套数据恢复计划： 数据恢复计划一：依据RAR压缩包文件的存储构造法则提取数据的开始地位，将备份数据库压缩包文件名和现有压缩包开始地位的文件名进行匹配，定位数据库压缩包的起始地位，复原这片压缩包的区域即可。数据恢复的过程非常顺利，解压复原进去的RAR格式文件时却报错“rar压缩文件底层损坏”。应用RAR修复工具对局部数据解压后查问，后果发现除局部网站代码外没有可用的数据库备份文件。计划一失败。 数据恢复计划二：SQL Server数据库通常会在第9页记录数据库库名，在每个页中都会记录数据库页编号&文件号。能够通过底层数据分析数据库起始地位，在底层扫描出合乎数据库页的数据碎片，利用数据碎片重组mdf文件，mdf文件重组后通过mdf校验程序检测文件的完整性，整个过程没有发现问题。搭建新的数据库环境，将复原进去的数据附加到环境中。施行过程截图： 附加胜利后通过数据恢复工程师和用户方工程师的重复检测，没有发现问题，确认复原进去的数据实现无效，本次数据恢复工作实现。

服务器故障：一台IBM DS存储呈现故障，存储调配给aix小机的卷无法访问。从底层查看调配给aix小机的3个卷的lvm信息失落。 服务器数据恢复过程：1、将存储中所有磁盘编号后取出，以只读形式做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后将磁盘依照编号还原到故障存储中。2、重组raid。a、基于镜像文件剖析硬盘底层数据，依据数据在硬盘中的散布法则找出RAID条带大小及RAID走向。raid条带就是将间断的数据划分为很多小局部别离存储到不同磁盘下来。raid的这个个性能够让多个过程同时拜访数据的多个不同局部而不会导致磁盘抵触。须要剖析出raid条带信息后能力进行raid重组的操作。b、RAID重组实现后，剖析所有数据LUN的分配情况。c、依据剖析出的LUN的散布地位和构造复原所有LUN。3、剖析vg內lv。因为3个vg内的lv信息都已失落，北亚企安数据恢复工程师依据aix lvm的调配策略和lv內文件系统的规定拼接每个lv。在复原的过程中发现大部分lv都是间断散布的，只有小局部lv存在碎片。尝试拼接后只有appvg下的backuplv，datavg下的idxdbs1拼接胜利。将找到的lv导出为镜像文件。4、复原数据。a、针对jfs2文件系统的lv，从底层提取外面的数据文件。b、针对存在db2表空间、informix表空间的lv，将导出的lv的镜像文件通过nfs共享给aix小机，而后通过dd命令将lv的镜像文件导入到aix中新建的lv中。 验证数据：1、验证数据库： 搭建数据库环境，数据库可失常启动。2、验证文件系统：在复原进去的文件中查找用户须要的文件，均可找到并可失常关上。

数据库故障&剖析：SQL server数据库数据无奈读取。通过初检，发现SQL server数据库文件无奈被读取的起因是因为底层File Record被截断为0，无奈找到文件结尾，数据表构造损坏。镜像文件的后面几十M空间和两头一部分空间被笼罩掉，零碎表损坏，无奈读取。思考用主动备份文件来提取表构造。日志中的操作记录： 因为零碎表损坏，有大量数据表的构造无奈确定，只能依附数据恢复工程师的技术和教训尝试进行复原。通过初检的后果，北亚企安数据恢复工程师团队最终敲定数据恢复计划：1、备份数据。2、基于备份文件剖析旧SQL server数据库底层数据。3、从旧SQL server数据库中寻找数据表的构造。4、从日志中提取一部分数据表的构造。5、从日志和残留数据中提取完整的数据。6、依据日志复原对应的数据，检查数据是否正确。7、数据核查没有问题后复原出所有数据。 数据库数据恢复过程：1、将波及到的所有硬盘交由硬件工程师进行物理故障检测，通过检测没有发现有硬盘存在物理故障。将每块硬盘以只读形式做全盘镜像，后续的数据分析和数据恢复工作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。对硬盘做镜像： 2、基于镜像文件剖析硬盘底层数据，发现底层残留许多以前SQL server数据库的日志和备份文件。通过查看剖析，发现日志中有很多包含插入语句的操作记录。在备份文件中发现建表语句和一部分旧数据。3、北亚企安数据恢复工程师编写提取SQL server数据库相干数据的小程序，扫描硬盘中所有存在的SQL server数据库残留数据并进行提取。4、剖析扫描到的所有日志文件，发现日志文件中的数据记录都有固定的结尾和结尾，每条数据在固定的地位都有object ID号。在接下来的扫描中，持续寻找有同样object Id的数据记录，发现这些数据记录构造雷同，由此能够判断这是完整的数据，能够提取。5、剖析扫描到的备份文件，发现能够通过提取其中的建表语句来失去一部分的表构造。对于残余的表构造，因为截断为0的局部刚好在零碎表，所以没有方法提取，只能依据从日志中提取进去的数据猜想表构造和数据类型。6、依据后面剖析的后果，北亚企安数据恢复工程师编写程序从备份文件中提取建表语句，依据建表语句剖析表构造与各种数据的类型。在残留的零碎表中寻找22H、07H、05H表，依据这些建设表与OBJECT_ID的对应关系。7、北亚企安数据恢复工程师编写程序提取日志中的记录，依据object ID来对应数据和表，并将数据插入到新表中。8、实现上述的所有操作后对数据进行验证，通过验证确认复原进去的新表与用工具察看到的数据基本一致。本次数据恢复工作实现。

服务器数据恢复环境：IBM P740小型机+AIX操作系统+Sybase数据库+V7000存储。V7000存储配置了12块SAS机械硬盘（其中一块为热备盘）组建一组raid5磁盘阵列。存储设备一共创立了2组Mdisk，加到一个pool中。 服务器故障：IBM V7000存储中的磁盘产生故障，工作人员更换磁盘后并进行数据同步，同步没有实现时候存储中的另块磁盘呈现故障，导致逻辑盘无奈挂接在小型机上，业务中断。通过存储设备的治理界面看到有2块磁盘显示故障脱机，其中10号位的故障盘为热备盘，3号位的故障硬盘状况如下图： 次要数据pool当初无奈加载，共三个通用卷均无奈挂载，如下图： 服务器数据恢复过程：将故障存储中所有磁盘编号取出，将没有问题的10块磁盘以只读形式做全盘镜像，产生故障的2块磁盘应用业余工具解决后做镜像。后续所有的数据分析和数据恢复操作都基于镜像盘进行, 防止对原始磁盘数据造成影响。 计划1、对存储进行强制上线操作。a、剖析故障存储中故障硬盘的离线程序。raid5最大容许一块成员盘离线，该存储设备曾经生效，各组Mdisk中只有一块硬盘离线。提取故障存储的日志，通过剖析日志能够失去各故障硬盘的离线程序。 b、修复后离线的故障硬盘。c、将修复的硬盘插回存储中进行强制上线操作。 计划2、解析存储构造。a、依据用户方给出的配置信息将硬盘依照Mdisk组分类。b、通过剖析每一组Mdisk中的所有硬盘获取到raid相干信息。c、虚构重组Mdisk。 d、通过剖析重组进去的Mdisk获取到pool的相干信息。e、解析pool在Mdisk上的散布状况，剖析pool中的条带大小。f、解析LUN位图，剖析各LUN在pool中的散布状况。g、北亚企安数据恢复工程师编写程序提取LUN。 服务器数据验证：随机抽样检测生成出的数据，没有发现问题。在用户方筹备好的存储设备上创立与原环境一样大小数量的LUN，将提取进去的数据LUN的镜像文件复制到存储上创立的LUN中。数据移交后，用户方工程师重新配置存储环境，通过检测一切正常。本次数据恢复工作实现。

EMC Isilon存储构造：Isilon群集存储系统应用的是分布式文件系统OneFS。Isilon群集存储系统的每个节点均为繁多OneFS文件系统，Isilon在进行横向扩大时不会影响数据的失常应用。Isilon群集存储系统所有节点在工作时都提供雷同的性能，节点没有主备之分。Isilon群集存储系统在存储文件时，OneFS层会将文件分成128K的片段别离寄存到不同的节点中，节点层又会将128K的片段分成8K的小片段别离寄存到该节点的不同硬盘中，用户文件的Indoe信息、目录项及数据MAP则会别离寄存在所有节点中。Isilon群集存储系统的这个个性能够让用户从任何一个节点拜访到所有数据。Isilon群集存储系统在初始化时会让用户抉择相应的存储冗余模式，不同的冗余模式所提供的数据安全级别也不一样（默认3个节点采纳N+2:1模式）。 服务器数据恢复环境：EMC Isilon S系列群集存储系统，3个节点，每个节点配置12块STAT硬盘。该存储系统寄存的数据是vmware虚拟机（WEB服务器）和视频文件。vmware虚拟机通过NFS协定共享到ESX主机，视频文件通过CIFS协定共享给vmware虚拟机（WEB服务器）。 服务器故障：管理员因为误操作将该存储系统中NFS协定共享的vmware虚拟机、MSSQL数据库以及大量的MP4、ASF和TS类型的视频文件删除。 服务器数据恢复过程：1、通过Isilon的web治理界面的集群敞开性能将存储设备失常关机，将存储系统中所有硬盘编号取出。由硬件工程师对所有磁盘进行硬件故障检测，通过检测所有磁盘均可失常读取，无物理故障。以只读形式将所有磁盘做全盘镜像，后续数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后将所有磁盘依照编号还原到存储设备中。 2、基于镜像文件剖析所有硬盘中的数据。因为数据是被人为手动删除的，不必思考存储的冗余级别。须要剖析的是文件被删除后文件Indoe及数据MAP是否发生变化。3、通过沟通和剖析，发现被删除的虚构磁盘文件都在64G或以上，并且存储中没有其余类型的大文件。北亚企安数据恢复工程师编写文件Indoe扫描程序，将文件大小64G或以上的Indoe都扫描进去。4、对扫描进去的Indoe进行剖析，发现Indoe中记录的数据MAP地位，其index指向的内容已不再是失常的数据。所有节点上的Indoe均是同样的状况。5、持续剖析Inode，发现大文件的数据MAP有多层（树结构），数据MAP中会记录文件的惟一ID，能够尝试找到文件最底层的数据MAP。对文件最底层的数据MAP做遍历跟踪操作，所幸找到最低层的数据MAP。6、从文件Inode中取出文件的惟一ID，聚合所有合乎该ID的数据MAP。依据数据MAP中的VCN号做排序，发现每个文件的前一万多项数据MAP都不存在，意味着每个文件的前一万多项数据没法复原。7、失落的数据MAP项大小不到1G，被删除的文件全是虚拟机的vmdk文件，外面都是NTFS文件系统，而NTFS文件系统的MFT根本都在3G的地位。只须要在每个vmdk文件的头部手动伪造一个MBR和DBR就能够解释vmdk外面的数据。8、对扫描到的数据MAP做解释，并依据VCN号的程序导出数据，没有MAP的状况保留为零。先导出一个vmdk文件做测试，后果导出的vmdk文件比理论状况要小，并且vmdk中MFT的地位也与本身形容不符。随机验证了几个MPA发现都能指向数据区，程序解释MAP的形式也都没有问题。所以猜想可能为文件稠密。9、将代码进行调整后从新导出方才的vmdk，这次导出的vmdk大小符合实际大小，且MFT的地位也与形容相符。手工伪造一个MBR、分区表和DBR，应用北亚企安自主开发的文件系统解释工具解释其文件系统，而后导出vmdk外面的数据库及视频文件。10、对vmdk中的数据库及视频文件进行验证没有发现问题后，批量导出所有vmdk文件，再手工一一去批改每个vmdk文件。 11、将所有数据恢复进去之后，交由用户方工程师对数据做完整性及准确性检测，通过重复检测，确认复原进去的数据残缺无效。本次数据恢复工作实现。

HP LeftHand存储简介：HP LeftHand存储反对搭建RAID5、RAID6、RAID10磁盘阵列，反对卷快照，卷动静扩容等。服务端和客户端别离如下： LeftHand存储共有三个级别：物理磁盘、基于多个物理磁盘组成的逻辑磁盘（raid磁盘阵列）、由不同的raid阵列组成的逻辑卷。 不同raid阵列中的多个不间断的片段组成卷，用于存储文件系统和用户数据。LeftHand能够辨认的最小单元是raid阵列，少数用户组成raid5或者raid6阵列（蕴含校验盘）。raid阵列均有map来存储这些不间断片段的空间。 上面分享一个HP LeftHand存储中raid数据恢复案例。 服务器数据恢复环境：某公司一台HP LeftHand存储，存储中有3组raid（一组raid0+1，2组raid5），两个卷，12块物理硬盘。 服务器故障：存储中的raid呈现故障无奈失常工作，管理员进行强制上线的操作后raid仍然不可用。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出。硬件工程师对故障存储中所有硬盘做物理故障检测，所有硬盘都能够失常读取，不存在物理故障。2、将故障存储中所有磁盘以只读形式做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。镜像实现后依照编号将所有硬盘还原到故障存储中。3、基于镜像文件剖析所有磁盘的底层数据。通过剖析发现存储中的RAID是一个HP双循环RAID5。第1组RAID5完整，产生故障的第2组RAID中至多有2块磁盘掉线。4、北亚企安数据恢复工程师应用穷举加校验的办法剖析出最早掉线的磁盘并将其踢出，而后利用剖析底层数据获取到的RAID相干信息重组raid。5、将生成的数据和完整的RAID5一起挂载到故障存储上并启动存储，下层卷可用。查看最新文件没有发现问题。6、由用户方工程师对复原后果进行验证，通过重复验证，确认复原数据残缺无效，本次数据恢复工作实现。

服务器数据恢复环境：HP某型号服务器，5块硬盘组建了一组raid5磁盘阵列。 服务器故障&剖析：服务器在工作过程中，raid5磁盘阵列中的一块磁盘掉线，因为raid5的容错特点，raid阵列未受影响，工作人员也没有及时关注磁盘离线的问题。服务器持续运行一段时间后呈现故障，管理员将现有的4块磁盘进行了重建raid的操作，重建后进行了数据同步，原raid5阵列中的数据全副失落。HP SMART ARRAY在创立一组新的RAID5时，默认会全盘重建所有的块校验。这意味着在组成新创建RAID5的任一条带中，总有一个校验块的数据是在创立raid时生成的，这个个性对于原raid阵列来说是极具破坏性的。通过剖析，后生成的4盘RAID5组成构造是双循环、64K块大小、16次条带换校验。这意味着新组建raid5的4块成员盘中，每隔3M就会有1M的数据是谬误的。原5盘RAID5的组成构造为双循环、块大小128K、16次条带换校验。要想复原数据必须修复早掉线的那块硬盘，数据恢复率取决于早掉线磁盘掉线之后数据变更多少。最终敲定的数据恢复计划：对新旧raid5组成构造的差异性进行剖析，用之前掉线的盘从新补回重建RAID时被毁坏的校验信息，再虚构重组RAID并解释文件系统，而后导出文件。 服务器数据恢复过程：1、将故障服务器中所有波及到的硬盘以只读形式进行全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成再次的毁坏。2、基于镜像文件剖析所有磁盘底层数据，依据毁坏前后的数据痕迹剖析新旧RAID5的构造。3、剖析新旧raid5组成构造差别，北亚企安数据恢复工程师编写校验修改程序。按原RAID5构造虚构重组RAID，生成镜像文件。4、由北亚企安数据恢复工程师修改重组后的镜像文件零碎谬误（所幸硬盘离线后数据变更很少，谬误极少）。5、导出局部分区数据，将局部分区在无谬误的前提下齐全镜像到筹备好的新空间。6、通过数据恢复工程师和用户方工程师的严格测试，确认复原进去的数据残缺无效。

服务器数据恢复环境：华为OceanStor某型号存储，十几块FC硬盘组建一组RAID5磁盘阵列，装备了一块热备盘；下层应用EXT3文件系统，配置了oracle数据库。 服务器故障：该存储RAID5中的一块硬盘未知起因离线，热备盘上线开始同步数据，同步未实现时候又有一块磁盘未知起因离线，数据同步失败，raid5瘫痪，下层lun不可用。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出进行物理故障检测，检测后发现为先掉线的磁盘存在物理故障，其余磁盘包含后掉线的那块磁盘均无物理故障。2、将所有磁盘以只读形式做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次影响。3、基于镜像文件剖析raid5中的所有磁盘底层数据，找出热备盘。raid是条带化的，阵列中的数据是依照肯定的法则进行存储的。数据恢复工程师剖析raid中的数据库页在每一个物理磁盘中的散布状况，计算出raid5的磁盘程序、数据走向、条带大小等RAID相干信息。4、依据剖析进去的RAID相干信息，应用北亚企安自主开发的RAID重构程序将原始RAID虚构重构进去。但因为原始RAID5中掉线了2块盘且有1块盘的数据被同步毁坏，剖析每一块硬盘中的数据后发现有一块硬盘在同一个条带上的数据和其余硬盘显著不统一，初步判断此盘是被同步毁坏的硬盘。通过北亚企安自主开发的RAID校验程序校验这个条带，最终确定被同步损坏的磁盘。5、剖析lun在raid5中的调配状态和lun调配的数据块，依据数据MAP导出LUN的数据。6、因为应用了热备盘虚构重构RAID，EXT3文件系统无奈失常挂载。7、提取oracle数据库文件，应用北亚企安自主开发的文件系统解析程序对其进行文件系统解析，而后导出oracle数据库文件。8、将导出的数据库文件移交给数据库工程师进行校验和验证。应用Oracle数据库文件检测工具检测每个数据库文件的完整性。如果发现错误，应用北亚企安自主研发的Oracle数据库检测工具进行二次检测。检测后发现局部数据库文件和日志文件谬误，system和sysaux表空间都存在坏块，管制文件全副损坏；eschoolspace表空间的几个文件存在的坏块更多；undotbs02失落；数据库数据恢复工程师对这些文件进行修复。 9、修复实现后，由用户方配合，启动Oracle数据库。在本地虚拟机装置OA客户端，通过OA客户端对数据记录进行验证。用户方安顿不同部门人员进行近程验证，通过重复验证，确认数据残缺无效。本次数据恢复工作实现。

服务器数据恢复环境：一台EMC存储中数块磁盘组建了一组raid5磁盘阵列，阵列中有2块热备盘；下层采纳ZFS文件系统，划分了一个lun，供sun小机应用。 服务器故障&检测：存储在失常运行中忽然解体无奈应用，管理员查看后发现raid5阵列中有两块磁盘离线，阵列中有两块热备盘，其中的一块热备盘激活失败，raid5阵列瘫痪，存储不可用。硬件工程师对raid5阵列中的两块离线的磁盘进行物理故障检测，发现这2块离线硬盘不存在物理故障和坏道。 服务器数据恢复过程：1、将故障存储中所有磁盘编号取出以只读形式做全盘镜像。镜像实现后将所有磁盘依照编号还原到原存储设备中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、镜像实现后将镜像数据的520字节扇区转换为512字节扇区，不便后续的数据恢复操作。3、依据RAID5磁盘阵列的工作模式，LUN都是基于RAID的。复原数据就须要先剖析RAID的底层信息，依据这些信息重构原始RAID阵列。数据恢复工程师基于镜像对所有磁盘底层数据进行剖析，发现阵列中2块磁盘离线，1块热备盘胜利激活，另1块热备盘却没有胜利激活，数据未同步。持续剖析数据在硬盘中散布的法则、RAID条带的大小、每块磁盘的程序等RAID相干信息。4、持续剖析RAID信息，发现有一块硬盘在同一个条带上的数据和其余硬盘显著不一样，初步判断此硬盘最先掉线。数据恢复工程师应用北亚自研RAID校验程序对这个条带进行校验后，确定最先掉线的硬盘。5、通过剖析进去的RAID信息虚构重构RAID。通过重构进去的RAID剖析lun的分配情况和数据块&导出lun所有数据。6、对导出的lun做ZFS文件系统解析，但解析时报错。数据恢复工程师手动查看文件，发现局部元文件损坏。7、北亚企安数据恢复工程师将这些损坏的文件系统元文件进行修复。通过对损坏的元文件进行剖析发现ZFS正在进行IO操作时存储瘫痪，局部文件系统元文件没有更新或者损坏。对这些损坏的元文件进行人工修复后，ZFS文件系统就可能失常解析。8、对修复好的ZFS文件系统做解析，解析所有文件节点及目录构造&导出，本次数据恢复工作实现。

服务器数据恢复环境：一台DELL EqualLogic PS系列存储，存储设备中12块磁盘组建一组raid5，文件系统是VMFS零碎；共划分3个卷。 服务器故障：存储设备在工作中忽然呈现故障无奈失常工作，其中有2块磁盘指示灯显示黄色，初步狐疑存储产生故障的起因是其中的磁盘呈现坏道。北亚企安硬件工程师将故障存储中的12块磁盘进行检测后，发现其中2块磁盘的坏道较多，SMART谬误冗余级别超过阈值。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，以只读形式进行全盘镜像。10块失常的磁盘能够失常镜像，2块发现坏道的磁盘须要在修复坏道后镜像。镜像实现后将所有磁盘还原到原存储设备中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 2、通过镜像文件对底层数据进行剖析，从镜像文件中归集日志信息。剖析日志信息找到这2块呈现坏道的磁盘以及这2块磁盘的掉线工夫，而后应用后掉线的那块磁盘进行数据恢复。3、通过剖析获取到的raid5相干信息虚构重构原始RAID，而后通过位图信息在重构的RAID中将3个卷全副提取进去。4、剖析底层构造信息，北亚企安数据恢复工程师将3个VMFS文件系统进行跨区卷组合。将数据导出后进行验证，没有发现异常。 5、将卷中的文件拷贝导出后进行虚拟机验证，虚拟机都能够失常启动。由用户方工程师对复原后果进行检测，确认复原数据残缺可用。本次数据恢复工作实现。

服务器数据恢复环境：HP EVA存储，6块SAS硬盘组建的raid5磁盘阵列。下层操作系统是WINDOWS SERVER。该存储为公司外部文件服务器应用。 服务器故障&剖析：在遭逢两次意外断电后，设施重启时raid提醒“无奈找到存储设备”。管理员尝试进入raid治理模块时死机，屡次重启尝试后故障仍旧。这是一个典型的因为意外断电导致raid硬件模块损坏或者riad治理信息失落等raid故障的状况。失常状况下，raid一旦创立实现，raid治理模块中的信息不会轻易更改，然而raid治理模块的信息是可批改的信息。一次或屡次的意外断电是有可能导致raid治理模块中的信息被篡改或失落，断电次数过多时甚至可能间接导致raid卡上的元器件损坏。该案例中的故障就是属于这种状况。 服务器数据恢复过程：1、首先由硬件工程师检测故障存储中的所有硬盘的物理故障，所有硬盘读取失常，没有发现存在显著的物理故障。2、将故障存储中所有磁盘以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。3、北亚企安数据恢复工程师基于镜像文件剖析底层数据，确定故障存储中6块磁盘的数据块大小、条带信息、盘序、校验形式等RAID信息，依据这些信息虚构重建raid阵列。4、逻辑校验重构RAID中的数据，在确认重构RAID各参数正确无误后，对所须要复原的数据进行齐全验证。5、在数据恢复工程师验证没有发现问题后，交由用户方亲自验证。通过重复验证，用户方工程师确认复原的数据残缺可用，达到预期。6、将数据迁徙至用户方筹备好的存储环境中，再次验证没有发现问题。 服务器数据安全Tips：1、尽量保障机房供电稳固，缩小供电异样对服务器和存储的影响。2、为重要的服务器及存储装备UPS，在意外断电的状况下能让外围业务持续运行一段时间，为应急计划的施行博得工夫。3、定期对服务工夫长的服务器和存储进行平安情况查看，对这些老旧设施的整体运行状态进行评估，及时更换硬件和降级软件，将可能的隐患提前排除。4、制订突发数据劫难的紧急解决计划，升高业务损失。

服务器数据恢复环境：IBM X系列服务器+柏科某型号存储。服务器上部署VMware ESXi虚拟主机，存储上寄存虚拟机文件。虚拟主机采纳的Windows Server操作系统，部署宏桥和索菲2套利用，数据库是SQL Server。虚构磁盘：数据盘（精简模式）+ 快照数据盘。 服务器故障：机房异样断电导致服务器上某台虚拟机无奈失常启动。管理员查看虚拟机配置文件，发现此虚拟机的配置文件除了磁盘文件外其余的配置文件全副失落，xxx-flat.vmdk磁盘文件和xxx-000001-delta.vmdk快照文件还在。分割VMware原厂工程师，VMware工程师须要新建一个虚拟机来解决故障问题，但发现ESXi存储空间有余。于是管理员将故障虚拟机下的xxx-flat.vmdk磁盘文件删除，而后VMware工程师重建了一个虚拟机并且调配了固定大小的虚构磁盘。 服务器数据恢复过程：1、在VMware vSphere Client上将挂载的存储设备中的VMFS卷卸载。而后将存储上的VMFS卷通过网线连贯到北亚企安备份服务器上，应用工具将整个VMFS卷以扇区的形式镜像到备份空间上。后续的数据分析和数据恢复操作均基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析VMFS卷的底层，发现异常断电导致故障虚拟机目录下的目录项被毁坏，然而不影响虚拟机的重要数据，能够通过人工进行修复。如果人为删除某个文件，目录项对应的数据区索引也会被同时清掉，然而不会影响删除文件的理论数据。能够依据被删除的虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在VMFS卷自由空间中进行碎片的匹配和合并这种形式来复原删除的虚构磁盘文件。然而本案例是在上述的两个问题同时产生的状况下又新建一台虚拟机并且调配了虚构磁盘。通过剖析发现新调配的虚构磁盘曾经全副清零了（在创立虚构磁盘的时候会抉择创立磁盘的类型），这个新建的虚拟机所占用的磁盘空间全副被清零。如果新调配的虚构磁盘占用了删除虚拟机磁盘所开释的空间，那么此局部空间的数据是无奈复原的。故障虚拟机的目录项区域： 3、通过北亚企安数据恢复工程师团队的会诊，最终确认服务器数据恢复计划：计划a、复原删除的VMDK文件。依据删除虚构磁盘文件中的文件系统以及虚构磁盘中的文件类型在VMFS卷的自由空间中进行碎片匹配和合并，复原删除的虚构磁盘文件。将快照文件和复原的虚构磁盘文件合并成一个残缺的虚构磁盘文件，而后利用文件系统解释工具解释虚构磁盘文件中的所有文件。计划b、复原MSSQL数据库文件。如果计划a施行成果不现实，能够依据SQL Server数据库文件构造对VMFS卷自由空间中合乎SQL Server页构造的数据区域进行统计、剖析和聚合，生成一个能够失常应用的.MDF格局的文件。计划c、复原MSSQL数据库备份文件。因为数据库每天都在做备份。如果上述2种计划施行过后还有一些数据库没有复原进去，就只能应用备份文件来复原数据库了。依据把握的备份文件.bak的构造，对VMFS卷自由空间中合乎SQL Server备份文件构造的数据区域进行统计、剖析和聚合，生成一个能够失常导入到SQL Server数据库中.BAK格局的文件。 4、服务器数据恢复施行过程：计划a施行过程：依照计划a进行底层剖析，依据VMFS卷的构造以及删除虚构磁盘的文件系统信息，在底层的自由空间中扫描合乎删除虚拟机磁盘的区域，统计其数量和大小是否合乎删除虚构磁盘的大小。依据虚构磁盘中文件系统的信息将这些扫描到的碎片进行排列组合，后果发现好多碎片缺失。从新扫描这些缺失的碎片，这些碎片的确无奈找到。将扫描到的碎片依照虚构磁盘原始的程序重组，没有找到的碎片暂且留空。应用虚构磁盘快照程序合并重组好的父盘和快照盘，生成一个新的虚构磁盘。解释虚构磁盘中的文件系统，因为缺失好多数据，文件系统解释过程中呈现很多报错，提醒某些文件损坏。 解析完文件系统后发现没有找到原始的数据库文件，而宏桥备份和索菲备份这两个目录的目录构造失常。然而尝试将备份导入到数据库中时，数据库导入程序提醒报错。 导入.BAK文件报错信息： 计划b施行过程：因为计划a中并没有将原始的数据库文件复原进去，并且很多备份文件无奈失常应用。因而采纳计划b来复原尚未复原进去的数据库文件。依据SQL Server数据库的构造去自由空间中找到数据库的开始地位。依据SQL Server数据库的结构特征，数据库的第9个页会记录本数据库的数据库名。依据这个特色核查该数据库的头部页是否是正在查找的。SQL Server数据库的每个页都会记录数据库页编号和文件号，依据这些特色北亚企安数据恢复工程师编写数据库扫描程序在底层扫描所有合乎数据库页的数据碎片。将扫描进去的碎片按程序重组成一个残缺MDF文件，通过MDF校验程序检测整个MDF文件的完整性。校检实现后发现只有cl_system3.dbf和erp42_jck.dbf这2个文件没有找到外，其余数据库均校验胜利。 cl_system3.dbf和erp42_jck.dbf因为底层有很多碎片没有找到（可能被笼罩），因而校验不通过。cl_system3.dbf文件中某个碎片失落的区域： 计划c施行过程：上述两个计划施行后并没有将所有的数据库文件全副复原进去。cl_system3.dbf和erp42_jck.dbf这2个文件因局部页缺失，无奈应用，须要采纳备份来复原这两个数据库文件。然而查看完这两个文件的备份后发现cl_system3.dbf因为备份机制没有备份进去，而erp42_jck.dbf只有某个月的全副增量备份。 因为erp42_jck.dbf文件中只缺失大量的页，能够依据缺失的页号在增量备份中查找到缺失的页，而后将找到的页补到erp42_jck.dbf文件中，从而复原一部分失落的数据库页。通过上述办法补完页后还是缺失局部页，无奈失常应用，只能通过北亚企安自主开发的数据库解析程序将erp42_jck.dbf文件中比拟重要的几十张表导出，并胜利导入到新建的数据库中。 验证数据：在一台服务器中搭建和原始环境一样的数据库环境，由用户方通过近程工具连贯到该服务器并装置宏桥利用。由用户方工程师验证数据库的完整性，通过重复认真验证后，确认数据库没有问题，下层利用能够失常运行，数据记录也根本没有缺失。数据库胜利挂载： 服务器数据恢复总结：本案例先是断电导致服务器中局部文件失落；而后人为删掉局部数据，又从新写入局部数据，导致局部数据被笼罩；又因为数据库备份机制导致局部数据库的备份不可用；所以本案例复原难度系数很高。因为北亚企安数据恢复工程师团队对SQL Server数据库底层构造有深刻的钻研，并且有解决相似故障类型的教训，所以能力顺利复原出用户须要的数据。

服务器数据恢复环境：华为OceanStor某型号存储，10块硬盘组成raid6磁盘阵列。下层操作系统采纳EXT3文件系统，划分2个lun。 服务器故障&剖析：在巡检中发现存储中的raid不可用，管理员进行了重新分配并初始化raid的操作，当初始化进度到40%左右时，管理员才发现自己的操作有问题，于是强行停止初始化，但局部数据曾经被毁坏。在发现raid不可用后，管理员将raid6中的9块数据盘重新分配为riad5阵列并进行了初始化操作，这些操作对原始数据造成不可逆的毁坏。 服务器数据恢复过程：1、将故障存储中所有磁盘以只读形式进行全盘备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析原始RAID6的构造以及重新分配的RAID5的构造。因为重新分配RAID的操作，底层数据中RAID6和RAID5的信息大量重合，北亚企安数据恢复工程师破费了大量工夫和精力剖析和区别这些数据。3、剖析出故障存储中原始raid6和重新分配的raid5的相干构造信息后，北亚企安数据恢复工程师开始钻研算法&编写程序&校对算法，将故障存储中原始raid6中的2个LUN别离镜像到筹备好的2个存储设备上。4、对第2个LUN进行验证后发现数据齐全失常，验证第1个LUN后发现这个LUN的前10MB重要数据被毁坏，EXT3文件系统的根目录和第一个块组的I节点全在这10MB数据外面。5、尝试应用几款罕用的数据恢复软件进行复原但成果都相当不现实，在这种状况下只能先对损坏的EXT3文件系统进行修复后能力进行下一步的操作。6、北亚企安数据恢复工程师编写小程序对EXT3文件系统进行目录查找。7、重建根目录和I节点，用EXT3文件系统解析程序关上已齐全失常。8、由用户方工程师亲自对复原进去的数据进行验证，通过重复验证，确认复原数据残缺可用。本次数据恢复工作实现。9、为了保障原始数据的权限和属性，在LINUX上将文件用cp命令拷贝到格式化为EXT3文件系统的单块磁盘的分区上。这样文件目录构造和属性都和原来截然不同，用户不再须要做任何其余的设置。

服务器数据恢复环境：某品牌存储，12块SAS硬盘组建RAID6磁盘阵列，划分一个卷，调配给几台Vmware ESXI主机做共享存储。卷中寄存了大量的Windows虚拟机，虚拟机通过模板创立的，系统盘大小统一，数据盘大小不确定，数据盘都是精简模式。 服务器故障：机房意外断电，电力供应恢复正常后存储无奈失常开机应用。通过用户方工程师诊断，初步判断是意外断电导致的存储设备中的磁盘阵列损坏。 服务器数据恢复过程：1、尝试将故障存储中所有磁盘以只读形式做全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。 2、在镜像的过程中发现大量损坏扇区。初步判断是因为这类硬盘的读取机制与惯例硬盘不一样。尝试更换主机、HBA卡、扩大柜和操作系统，均呈现雷同的故障。与用户方工程师沟通后得悉raid控制器对磁盘并没有特殊要求。3、对硬盘损坏扇区的散布法则进行检测，发现以下法则：a、损坏扇区以256个扇区为单位散布。b、除了损坏扇区片断的起始地位不固定，前面的损坏扇区都是以2816个扇区为距离。所有磁盘的损坏扇区散布如下表（只列出前3个损坏扇区）：4、北亚企安数据恢复工程师编写小程序对每个磁盘的损坏扇区做绕过解决，用此程序镜像完所有磁盘的数据。5、基于镜像文件剖析损坏扇区，发现损坏扇区呈规律性呈现：a、每段损坏扇区的区域大小为256。b、损坏扇区散布为固定区域，每跳过11个256扇区就会遇到一个坏的256扇区。c、损坏扇区的地位总是位于RAID的P校验或Q校验区域。d、所有磁盘中只有10号盘有一个天然坏道。6、通过剖析扇区得悉分区大小（扇区数）。依照RAID6的模式计算后得出的后果和raid控制器中保留的RAID信息区域大小吻合。依据物理硬盘底层体现，分区表大小为512字节，前面无8字节校验，大量的0扇区也无8字节校验。综合以上信息能够确定故障存储并未启用DA技术(520字节扇区）。分区大小如下图(GPT分区表项底层体现，涂色局部示意分区大小，单位512字节扇区，64bit)： 7、重组RAID。a、存储应用的是规范的RAID6阵列。整个存储被划分为一个卷并调配给几台ESXI做共享存储，因而卷的文件系统是VMFS。VMFS卷中寄存了大量的Windows虚拟机，Windows虚拟机应用的NTFS文件系统，能够依据NTFS中的MFT的程序剖析出RAID条带的大小以及RAID的走向。b、镜像完所有磁盘后发现最初一块硬盘并没有像其余磁盘一样有大量的坏道。这块磁盘中有大量的未损坏扇区，这些未损坏扇区基本上是全0扇区，能够判断这块硬盘是热备盘。c、依据剖析进去的RAID相干信息重组RAID。重组实现后能够看到目录构造，然而不确定是否为最新状态。检测几个虚拟机发现有局部虚拟机的数据异样，初步判断RAID中存在掉线的磁盘。将RAID中的每一块磁盘顺次踢掉后再查看方才数据异样的中央，没有发现问题起因。仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统层面。如果VMFS文件系统大于16TB，就会存在一些其余的记录信息，组建RAID时候须要跳过这些记录信息。再次重组RAID后查看以前数据异样的中央，发现问题曾经解决了。筛选其中的一台虚拟机做验证，将所有磁盘退出RIAD中后，发现这台虚拟机是能够启动的，但在缺盘的状况下启动就呈现问题。因而能够判断该RAID在不缺盘的状态下为最佳。 8、验证虚拟机。对重要的虚拟机做验证，发现大部分虚拟机能够开机进入登录界面。只有有少部分虚拟机开机蓝屏或开机检测磁盘，然而通过光盘修复之后都能够失常启动。 9、验证数据库。针对重要虚拟机中的数据库做验证，数据库都失常。然而有一个数据库，据用户形容如同短少局部数据，然而通过认真核查后发现这些数据在数据库中原本就不存在。通过查问master数据库中的零碎视图，查出所有数据库信息如下： 10、查看VMFS卷的完整性。因为虚拟机数量较大，对每台虚拟机进行验证不太事实。所以咱们对整个VMFS卷做检测，在检测VMFS卷的过程中发现局部虚拟机或虚拟机文件被毁坏。 11、批量复原数据。筹备指标磁盘，组建一个RAID阵列。将重组的RAID数据镜像到指标阵列上，而后利用北亚企安自研程序解析整个VMFS文件系统&提取VMFS卷。 12、移交数据。在北亚企安数据恢复工程师的帮助下，将复原进去的数据迁徙到用户方筹备好的环境中。

服务器数据恢复环境：HP ProLiant DL某系列服务器，三块SAS硬盘组建raid阵列。下层零碎部署有数据库，数据库寄存在D分区，备份寄存在E分区。 服务器故障：磁盘故障导致RAID瘫痪，其中一块硬盘状态灯显示红色。寄存数据库文件的D分区无奈辨认；E分区可辨认，然而拷贝备份文件报错。管理员重启服务器，离线硬盘上线进行数据同步。同步还没有实现时，管理员发现异常，将服务器强制关机，之后没有对服务器做任何操作。 服务器数据恢复过程：1、将故障服务器中所有磁盘编号取出，连贯到北亚企安备份服务器平台上以只读形式进行全盘备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。在备份过程中发现阵列中的三块磁盘能够失常读取，均没有发现坏道。 2、基于镜像文件剖析底层数据获取raid相干信息，依据获取到的raid信息重组raid并进行异或校验，然而只有局部校验通过。因为离线硬盘上线之后的同步操作会毁坏数据，只有局部校验通过意味着数据有损坏。 3、尝试多种硬盘离线状态上来提取数据，发现每块盘离线所提取的数据都是统一的。 4、尝试剖析&修复E分区中的dat文件，发现两个备份文件都有损坏。 5、剖析&聚合dat碎片，验证dat数据的完整性，底层构造显示有损坏。 6、剖析扫描D分区的数据文件，因为离线硬盘上线之后的同步操作，数据文件目录曾经找不到了。 7、扫描D分区的自在空间数据页，在扫描的后果中发现较间断的数据片段，碎片可用。北亚企安数据恢复工程师剖析&聚合文件碎片，验证数据文件碎片的完整性和有效性。8、北亚企安数据恢复工程师通过整合拼接D分区碎片和E分区备份文件修复&解析出数据，提取数据记录到新建的数据库中。9、将下层利用连贯数据库，验证数据的可用性。通过验证，数据库文件能够失常加载，下层利用中的用户账号失常，能够进行失常的数据查问。10、由用户方工程师亲自验证数据，确定复原进去的数据残缺可用。将数据迁徙到用户方筹备好的环境中。本次数据恢复工作实现。

服务器数据恢复环境：DroboPro FS网络存储，数块SAS硬盘组建的raid5磁盘阵列。 服务器故障：存储中有一个共享文件夹因为未知起因失落。 服务器数据恢复过程：1、将故障存储中所有磁盘接到北亚企安数据恢复平台上以只读形式做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。2、基于镜像文件进行数据分析。通过对镜像文件的检测剖析，数据恢复工程师判断存储中该共享文件夹失落是因为存储底层零碎谬误导致的。3、故障存储设备上是一组由数块硬盘组建的RAID5磁盘阵列，该型号存储设备构造较简单，要复原其中的失落的数据须要先搞清楚该存储设备的存储构造。经用户方批准后，数据恢复工程师对故障存储设备的存储构造进行测试。通过测试，发现该存储底层应用ext4文件系统对文件构造进行治理，在下层又应用另外的构造对ext4文件系统进行治理，下图为存储中管理文件构造的ext文件系统的超级块构造： 4、基于镜像文件剖析原始数据，查看底层ext4文件系统的完整性。通过剖析，发现所丢的失共享文件夹局部构造残缺，但有局部节点索引失落。5、因为该存储构造较简单，应用多层索引构造对整体空间进行治理，北亚企安数据恢复工程师团队破费大量工夫对一些构造细节进行测试与钻研，最终搞清楚该型号存储设备的存储构造。6、依据故障存储的存储构造，北亚企安数据恢复工程师编写程序解析&提取存储中的数据。7、因为ext4文件系统中局部节点索引损坏，有局部数据没有复原进去。通过用户重复验证，该共享文件夹中重要数据全副都复原进去了，确认复原后果无效。

服务器数据恢复环境：IBM TotalStorage DS系列存储，蕴含一个存储机头和多个存储扩大柜，磁盘柜中的磁盘创立了多组RAID5。其中6号扩大柜中的RAID5由15块成员盘和1块热备硬盘组成。 服务器故障：6号扩大柜中的一块硬盘离线，热备盘替换上线并开始同步数据。在热备盘同步数据的过程中，又有一块磁盘呈现故障离线，热备盘同步数据失败，RAID5磁盘阵列生效，卷无奈挂载拜访。 服务器数据恢复过程：1、将呈现故障raid的扩大柜中的所有磁盘以只读形式做全盘镜像, 后续的数据分析和数据恢复操作都基于镜像盘进行, 防止对原始磁盘数据造成二次毁坏。2、基于镜像文件剖析故障raid构造，依据剖析获取到的raid相干信息虚构重组raid，重组实现后应用自主开发的程序将该raid中的所有lun提取进去。3、将重新配置的lun映射到复原服务器，将提取进去的lun文件一对一拷贝到新创建的lun中。4、将lun全副胜利映射回原服务器，通过查看没有发现问题。交由用户验证数据，却发现有局部目录没有找到。5、通过北亚企安数据恢复工程师的仔细检查，发现lun6的局部数据错乱，于是从新提取lun6。6、实现从新提取后再次映射回原服务器。由用户再次查验，通过重复检测，没有发现什么问题，确认复原进去的数据无效。 服务器数据恢复论断：存储系统呈现故障后，用户没有做任何破坏性的或者可能存在危险的操作，原始环境保留完整，保障了后续数据恢复工作的顺利进行。

服务器数据恢复环境&故障：华为OceanStor T系列某型号对立存储，反对SAN和NAS存储协定。工作人员在巡检时发现存储设备上一个NAS卷中的数据失落。该卷中的数据包含office文档、PDF文件、图片（JPG、JPEG、PNG等），视频文件（MP4、AVI等），音频文件（MP3等）。发现问题后管理员立刻关闭系统利用，进行上传数据。 服务器数据恢复过程：1、找到失落数据的NAS卷所对应的服务器LUN，该NAS卷对应两个LUN。将对应的LUN映射至备份服务器，以只读形式对LUN进行残缺镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析服务器LUN的构造，解析该NAS卷对应的两个LUN之间的关系。LUN1： LUN2：3、剖析该NAS卷在两个LUN中的散布状况并虚构重组该卷。4、剖析该NAS卷的存储构造，获取文件系统类型、超级块、节点等构造。5、剖析该NAS卷中的超级块、节点等构造，获取节点、目录项、数据区之间的索引关系。超级块： 节点：6、北亚企安数据恢复工程师编写程序解析目录项、节点并提取数据。 服务器数据恢复后果：1、扫描该NAS卷的全副空间，发现文件系统的目录项还在，然而节点曾经全副失落，查看文件系统的日志也没有找到无效的节点。 找到的局部目录项： 节点： 2、尝试按类型间接复原数据文件，而后依据目录在卷中的偏移地位&数据文件在卷中的偏移地位&客户提供的对应文件类型、文件大小去匹配目录项和数据文件，通过一番致力后胜利匹配用户所须要的数据。通过用户重复验证后确认复原进去的数据残缺无效。本次服务器数据恢复工作实现。

服务器数据恢复环境：北京某公司的EMC NAS，总共有3个节点，每个节点配置12块STAT硬盘。NAS中寄存有vmware虚拟机（WEB 服务器）和视频文件。虚拟机通过NFS协定共享到ESX主机，视频文件通过CIFS协定共享给虚拟机（WEB服务器）。 服务器故障：因为工作人员误操作将包含MSSQL数据库，大量MP4、ASF和TS格局的视频文件删除。NFS共享的所有数据（虚拟机）被删除而CIFS共享的数据则没有被删除。 服务器数据恢复过程：1、对故障存储中所有硬盘以只读形式进行全盘镜像。后续的数据分析和数据恢复操作都基于镜像进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析所有硬盘中的数据。因为数据是被人为删除的，须要剖析文件被删除后，文件的Indoe及数据MAP是否发生变化。3、因为被删除的虚构磁盘文件大小都在64G或者以上，而且存储中没有其余类型的、文件大小超过64G的大文件。北亚企安数据恢复工程师编写Indoe扫描程序，将大小合乎64G或以上的文件的Indoe都扫描进去。4、剖析扫描进去的Indoe，找出数据MAP地位，其index指向的内容不是失常数据，并且所有节点上的Indoe均是同样的状况。5、剖析Inode，发现大文件的数据MAP会有多层（树结构）,并且数据MAP中会记录文件的惟一ID，因而能够尝试找到文件底层的数据MAP。6、对文件底层的数据MAP做遍历跟踪操作后发现底层的数据MAP果然还在。7、从文件的Inode取出文件的惟一ID，聚合所有合乎该ID的数据MAP。依据数据MAP中的VCN号排序，发现每个文件的前17088项数据MAP都不存在，这意味着每个文件的前17088项数据没法复原。8、通过换算发现失落的数据MAP项总共蕴含不到1G的数据，而删除的文件全是虚拟机的vmdk文件,外部采纳的NTFS文件系统，而NTFS文件系统的MFT根本都在3G的地位，也就是只须要在每个vmdk文件的头部手动伪造一个MBR和DBR就能够解释vmdk外面的数据。9、解释扫描到的数据MAP，依据VCN号的程序导出数据，没有MAP的状况就保留为零。通过一直的测试，尝试导出一个vmdk文件，发现导出的vmdk文件比理论状况要小，并且vmdk中MFT的地位也与本身形容不符。10、随机验证几个MAP发现都能指向数据区，程序解释MAP的形式也都没有发现问题。所以初步判断呈现这种状况的起因可能是文件稠密。11、调整代码后从新导出方才的vmdk文件，这次vmdk文件大小符合实际，且MFT的地位正确。手工伪造一个MBR、分区表以及DBR，应用北亚企安自主开发的文件系统解释程序胜利解释其文件系统，导出该vmdk文件里的数据库及视频文件。12、验证此vmdk中的数据库及视频文件没有问题后，批量导出所有的vmdk文件，再手工批改每个vmdk文件。直至复原出所有用户须要的数据。 服务器数据验证：将所有重要数据恢复实现后，由用户方安顿工程师对复原进去的数据做完整性及准确性验证。通过重复验证测试，用户方确认数据残缺无效。本次数据恢复工作实现。

存储数据恢复环境&故障：H3C FlexStorage某型号存储，25块磁盘组建的RAID5，其中蕴含一块热备盘。工作人员误操作将存储设备中原先的2个卷删除，删除之后又应用和删除2个卷同样大小的空间重建了一个卷。用户心愿复原删除的2个卷中的一个。 存储数据恢复胜利可能性剖析：该型号H3C FlexStorage存储反对精简、快照等性能。该型号存储中的卷被删后是否能复原分为以下几种状况：1、删除卷并重建卷之后没有进行任何数据的写入操作，可残缺复原被删卷中的数据。2、在重建卷之后，存储自身没有对新卷进行初始化操作，数据保留应较为残缺，复原被删卷数据的概率十分高。3、对存储中磁盘的底层数据进行检测，查看卷被删除之后，相干的map信息是否也被革除，若map信息还有保留，残缺复原被删卷的可能性比拟大，4、卷被删除之后，map信息也被革除，则无奈残缺复原被删卷，只能尝试通过拼接片段来复原被删卷中的数据。 存储数据恢复过程：1、将故障存储中的所有硬盘编号后取出，以只读形式做残缺镜像备份，所有磁盘都能够失常读写，在备份过程中也没有发现大量坏道。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、通过和用户沟通，删除并重建卷之后，存储设备没有进行过大量的数据写入。基于镜像文件对底层数据进行剖析，发现卷被删除的同时map信息也被革除了，只能采纳拼接片段来复原数据。3、应用北亚企安自主开发的片段扫描工具对被删卷所在空间进行扫描，尽可能将所有片段都扫描进去。4、北亚企安数据恢复工程师编写程序拼接片段，拼接实现后提取数据。5、数据恢复工程师搭建环境对数据进行检测，没有发现问题后交付给用户方工程师进行检测，通过重复检测，用户方确认复原进去的数据残缺无效。6、在用户方工程师的帮助下，将复原进去的数据迁徙至用户方提前准备好的环境中。本次数据恢复工作实现。

数据库数据恢复环境：一台Dell PowerEdge某型号存储，数块SAS硬盘别离组建raid1和raid5两组磁盘阵列。其中2块磁盘组建的RAID1，用于装置操作系统；其余几块磁盘组建raid5，用于存放数据。下层装置的windows服务器，部署有sql server数据库，sql server数据库寄存在C盘分区。 数据库故障&剖析：管理员发现寄存sql server数据库的C盘残余空间有余，于是将数据库门路指向D盘，在D盘生成了一个.ndf文件。大概半个月之后，数据库呈现故障，无奈连贯和附加查问。因为数据库文件所在磁盘的容量有余，数据库无奈失常运行，呈现逻辑谬误。 数据库数据恢复过程：1、将存储设备中所有磁盘以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析存储中RAID1和RAID5的构造，获取RAID相干信息，利用这些信息虚构重组RAID1和RAID5。3、因为管理员在发现数据库呈现故障之后进行过屡次数据库复原操作。每次复原操作都是在原环境下进行的，导致原始的数据库文件被更改笼罩，磁盘空间被屡次复写，所以无奈应用尝试复原之后的数据库文件进行修复。所幸的是，通过沟通得悉在数据库产生故障的时候，对原始数据库文件进行过备份。4、从虚构重组进去的RAID5的空间中将管理员备份的数据库文件拷贝进去，尝试在数据库中附加，附加失败，谬误提醒如下： 谬误提醒主数据库文件和次级数据库文件不匹配。5、查看.ndf文件底层，发现该文件中简直没有数据。尝试勾销.mdf文件和.ndf文件之间的关联并只用.mdf文件进行附加，仍然报错但谬误提醒发生变化。谬误提醒如下： 谬误提醒日志文件（.ldf）和数据库文件（.mdf）不匹配。6、尝试对数据库进行无数据库附加，附加胜利。然而发现数据库系统表损坏，无奈失常应用。 7、尝试修复数据库的零碎表，但零碎表损坏过于重大，无奈修复。8、北亚企安数据恢复工程师编写程序解析&提取数据库文件中的数据库记录。9、依据数据库备份获取数据库的表构造，重构表构造并将提取出的数据库记录导入到新的表中。 数据验证：由用户方对提取出的数据库记录进行验证，通过重复验证，确认数据残缺无效，本次数据恢复工作实现。 Tips：部署数据库时要正当调配数据库文件所在磁盘的空间，及时清理垃圾数据，保障数据库的失常、平安运行。

服务器数据恢复环境：某公司一台服务器中组建一组raid5磁盘阵列；下层操作系统为linux redhat，部署OA零碎，后端数据库为oracle。 服务器故障&初检：raid5中有2块磁盘先后掉线，服务器解体。oracle曾经不对该OA零碎提供后续技术支持，用户方要求复原数据和操作系统。通过初步检测，发现热备盘没有启用，硬盘无显著的物理故障和同步体现。 服务器数据恢复过程：1、将故障服务器中所有硬盘做好标记，取出后挂载至只读环境，对所有硬盘以只读形式做齐全镜像备份，镜像过程中发现有一块磁盘（2号盘）有大量坏扇区，其余磁盘均没有发现坏道。镜像实现后将硬盘依照编号还原至原服务器，之后的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析RAID构造，获取到原RAID级别，条带规定，条带大小，校验方向，META区域等RAID相干信息。剖析构造：失去的最佳构造为0,1,2,3盘序，缺3号盘，块大小512扇区，backward parity(Adaptec)。raid构造：3、检测虚构重构的RAID构造是否正确，通过检测发现200M以上的最新压缩包解压无报错，确定构造正确。间接按此构造生成虚构RAID到一块单硬盘上，关上文件系统无显著报错。4、确定备份包平安的前提下，经用户方批准后，北亚企安数据恢复工程师用全新硬盘更换损坏的2号盘，而后对原盘重建RAID。将复原好的单盘用USB形式接入故障服务器，再用linux SystemRescueCd启动故障服务器，之后通过dd命令进行全盘回写。5、实现回写后启动操作系统，后果发现无奈进入零碎并报错，报错信息为：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。狐疑此文件权限有问题，用SystemRescueCd重启后查看发现此文件的工夫，权限，大小均有显著谬误，显然是节点损坏。6、从新剖析&重组数据中的根分区，定位出错的/sbin/pidof，发现问题是由2号盘坏道导致的。7、通过raid中的另外3块盘对2号盘的损坏区域进行xor补齐。补齐后从新校验文件零碎，仍然有谬误，再次查看inode表，发现2号盘损坏区域有局部节点体现为下图中的55 55 55局部。 8、很显著，尽管节点中形容的uid还失常存在，但属性，大小和最后的调配块全部都是谬误的。依照所有的可能进行剖析后，的确没有任何方法能找回此损坏节点。只能尝试修复此节点或复制一个雷同的文件过去。9、北亚企安数据恢复工程师对所有可能有谬误的文件通过日志确定原节点块的节点信息并做修改。10、修改后从新dd根分区，执行fsck -fn /dev/sda5进行检测，呈现报错： 报错提醒在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析，发现因3号盘早掉线，存在节点信息的新旧交加。11、按节点所属的文件进行区别，革除谬误节点后再次执行fsck -fn /dev/sda5进行检测，仍然有极少量的报错信息。依据报错信息的提醒，发现这些节点多位于doc目录下，不影响零碎的启动，于是间接执行fsck -fy /dev/sda5强行修复。12、修复实现后重启零碎，胜利进入零碎桌面。启动数据库服务，启动OA零碎，一切正常，无报错。13、由用户方工程师亲自验证，通过重复验证，确认复原后果无效。至此，本次数据恢复工作实现。

服务器数据恢复环境：一台HP DL系列服务器，通过hp smart array控制器挂载一台磁盘阵列设施，作为公司外部的文件服务器应用；该磁盘阵列设施中有一组由十几块SCSI硬盘组建的RAID5；下层装置LINUX操作系统并部署了NFS+FTP。 服务器故障&初检：服务器和磁盘阵列设施从老机房搬迁到新机房，将所有线路连贯好后开机发现服务器无奈辨认RAID，提醒未初始化。工程师对故障设施进行初检，发现数据失落的起因是raid信息失落，RAID采纳双循环的校验形式。 服务器数据恢复过程：1、将SCSI硬盘柜连贯到无RAID性能的SCSI扩展卡上。将故障服务器中所有硬盘以只读形式做残缺镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析原RAID的双循环校验参数以及其余raid信息，北亚企安数据恢复工程师依据获取到的raid信息重组虚构raid。3、在重组好的RAID中剔除掉较早离线的硬盘，由北亚企安数据恢复工程师编写程序解释文件系统，文件系统解释实现后曾经能够导出raid数据。4、将用户方的HP服务器连贯盘阵并重新配置RAID。5、通过网络dd、NFS、SAMBA、FTP、SSH等数据传输方式将所有数据传回新建的raid磁盘阵列中。6、由用户方工程师对复原进去的数据进行检测，通过重复检测，确认复原进去的数据残缺无效。本次数据恢复工作实现。 服务器数据安全Tips：1、尽量保障机房供电稳固，缩小供电异样对服务器和存储设备的影响。2、为运行重要业务的服务器及存储设备装备UPS。这样在断电的状况下能够保障外围业务能持续运行一段时间，为施行应急解决方案博得贵重的缓冲工夫。3、定期对服务年限较长的服务器和存储设备进行平安情况查看，对其运行状态进行评估以决定是否进行硬件或者零碎的全面降级。4、提前制订数据劫难应急解决计划，升高因为数据劫难带来的经济损失。

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

存储数据恢复环境：NetApp存储设备，WAFL文件系统，底层是由多块硬盘组建的raid磁盘阵列。 存储故障：工作人员误操作导致NetApp存储内局部重要数据被删除。 存储数据恢复过程：1、将存储设备的所有磁盘编号后取出，以只读形式做全盘镜像备份，镜像实现后将所有硬盘依照编号原样复原到存储设备中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止数据恢复过程中可能对原始数据造成二次毁坏。2、基于镜像文件进行底层数据进行二进制剖析，搞清楚故障存储中数据分布状况以及raid阵列的相干信息。3、获取到存储中数据的散布状况剖析出raid阵列的相干信息后，北亚企安数据恢复工程师利用获取到的raid信息虚构重组出一个raid阵列。4、实现raid阵列重组后，在Raid根底之上重构Storage Pool并导出失落数据的逻辑卷。5、测试WAFL文件系统。对NetApp存储进行底层WAFL文件系统差异化测试，剖析差别区域的规定。6、北亚企安数据恢复工程师编写WAFL文件系统解析程序，对失落数据的卷进行文件系统解析。7、剖析被删文件的节点索引信息，北亚企安数据恢复工程师编写程序主动解析被删文件的索引和删除节点进而复原误删的数据。8、验证数据。在验证数据的过程中如果发现有数据不全或其余的问题，反复下面的步骤直到胜利复原出所有数据。 该计划实用于netAPP其余型号存储的误删除数据的复原。

虚拟机数据恢复环境：ESXI上共有数十台虚拟机，EXSI连贯一台HP EVA存储，所有虚拟机都寄存在该EVA存储上。其中一台虚拟机是数年前从物理机迁徙过去的，其上部署了一个SQL SERVER数据库，该数据库寄存了最近几年的数据。 虚拟机故障&剖析：工作人员的误操作不小心还原快照了。这个快照是数年前做完数据迁徙后新建的，还原快照就意味着虚拟机数据还原到几年前刚做完数据迁徙时的状态，近几年的数据都被删除了。还原快照相当于删除数据，意味着底层的存储空间会被开释。为了不让这部分开释的空间被新写入的数据从新应用，必须将连贯到这台EVA存储的所有虚拟机都关机。如果有十分重要的虚拟机不能长时间关机，就须要将这些重要的虚拟机迁徙到别的EXSI上。刚好本案例中有一台虚拟机不能关机，只能做热迁徙。vmware虚拟机的热迁徙须要建设多个快照来实现。 Tips：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、依据Vmware快照原理，提取整个vmfs中闲暇的MAP。2、北亚企安数据恢复工程师在闲暇的MAP中找出合乎快照文件头构造的MAP。3、依据快照文件的构造，提取快照文件剩下的碎片。4、实现快照文件的提取后，北亚企安数据恢复工程师将快照文件和原vmdk合并生成新的vmdk。5、新生成的vmdk蕴含了所有的数据，挂载新的vmdk并解释外面的数据。

服务器数据恢复环境：同友存储，底层由数块物理硬盘组建的raid5磁盘阵列，存储池划分若干lun，每个lun下无数台虚拟机。 服务器故障：未知起因导致存储解体，无奈启动，虚拟机全副失落，其中一个lun中的3台虚拟机数据尤为重要，须要复原其中的数据。 服务器数据恢复过程：1、将故障存储中的所有磁盘以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。 2、基于镜像文件剖析raid5阵列，发现故障存储中的raid5阵列缺失2块磁盘，热备盘曾经启用。通过理论状况能够推断故障产生的大抵过程：第一块硬盘掉线后raid5启动热备盘替换。第二块硬盘掉线后raid5降级，第三块硬盘掉线导致raid5阵列解体。这种状况下个别是无奈通过校验间接获取到缺失盘的数据，只能应用磁盘等同大小的全0的空镜像进行raid重组（依赖空镜像组建的raid的文件系统构造会重大损坏，相当于每个条带都缺失两个块的数据，所以除非凡状况外不倡议如此操作）。 重建raid： 3、通过重组进去的raid5阵列提取LUN。通过对存储构造的进一步剖析获取到存储划分的MAP块，对各个LUN的数据块指针进行解析并由北亚企安数据恢复工程师编写程序提取LUN碎片。碎片提取实现后进行碎片拼接，组成残缺的LUN。 提取LUN： 4、导出LUN内所有虚拟机并尝试启动，后果因为操作系统被毁坏，虚拟机无奈启动。5、提取虚拟机内的文件，但虚拟机内的文件少数损坏重大，只有多数文件可用，只能通过其余计划进行复原。6、本次须要进行数据恢复的虚拟机内有mysql数据库，能够依据mysql数据库底层存储的特殊性扫描数据页并提取数据。 数据恢复过程截图： 7、依据mysql数据页特色扫描数据页并导出数据（仅实用于innodb引擎数据库，myisam引擎数据库没有“数据页”概念），剖析零碎表获取各用户表信息，依据各个表的id宰割数据页。8、因为该数据库的表构造变更过屡次，存储故障导致系统表的局部数据失落，所以记录提取过程十分苦楚（这里不赘述）。获取最早版本数据库各个表的表构造。因为合并快照前的父盘因为写入较早，应用第一块掉线盘进行校验获取到残缺数据，而后提取出其中数据库各个表的表构造。用户方提供了最新版本数据库的建表脚本。别离应用两组不同表构造提取数据记录并导入到搭建好的环境中的mysql数据库内，剔除各个表中因为表构造变更所导致的乱码数据，最初将两组数据别离导出为.sql文件。 数据验证：两个版本的数据库表构造不同，先分割用户方工程师进行调试，调试实现后导入平台进行测试，平台测试胜利，本次数据恢复工作实现。

服务器数据恢复环境&故障：某品牌StorageWorks存储设备，8块磁盘组建一组raid5磁盘阵列。存储中2块磁盘掉线导致阵列解体，通过查看发现掉线的2块磁盘均存在物理故障。 服务器数据恢复过程：1、硬件工程师对掉线的两块磁盘进行检测，加电后磁头无奈寻道，拆散PCB并清洁HDA组件后再次尝试加电，磁头仍然无奈寻道，须要进行物理修复。通过简单的修复过程（此处略过）后2块故障硬盘能够失常辨认。2、将故障存储内所有磁盘以只读形式进行镜像备份，后续数据分析和数据恢复操作都基于镜像文件进行，防止在复原数据的过程中对原始数据造成二次毁坏。3、基于镜像文件剖析故障存储设备中硬盘的底层数据，发现所有磁盘的0扇区呈现了“55 AA”（0x01C2H处示意该分区的类型，显示“05”就示意这是一个扩大分区，从0扇区看这是一个不失常的 MBR 分区构造）。7号盘和8号盘的0扇区也找到了“55 AA”的标记。8号硬盘是一个失常的MBR分区，其0x01C6处的数值代表指向的下一个扇区为GPT的头部。 7号硬盘0x01C6处的数值代表指向下一个扇区，然而下一个扇区很显著不是GPT的头部。 通过下面的剖析，北亚企安数据恢复工程师初步判断阵列中的8号盘和7号盘别离为第一块和最初一块硬盘，GPT分区所在扇区起始于172032扇区，因而初步确定LUN的起始扇区是172032扇区。4、通过剖析raid确定了条带大小为1024个扇区。依照1024扇区进行宰割，使一个记录为一个条带的大小。5、当7块盘都定位到同一地位时，通过比照能够判断校验区的走向，继而判断整个RAID5的走向。之前曾经判断出8号盘是第一块盘了，把8号盘放在第一个地位，确定RAID5的走向和盘序。6、下面曾经初步确定了LUN的起始扇区是172032扇区，跳转到172032扇区进行察看，失常状况下这个扇区所属条带中的5号盘应该是校验区，但理论显示校验区为8号盘。依据该raid左走向的法则，5号盘的校验区应该在172032-1024=171008扇区，即上一个条带。跳转到171008扇区，发现校验区为5号盘。因而能够确定LUN的起始扇区为171008扇区。7、依据下面步骤中获取到的raid相干信息应用工具重组raid。8、因为数据从1024 * 8=8192个扇区开始，刚组好的RAID必须和一个文件再进行一次重组操作。RAID的起始扇区(Start sectors)抉择8192，这个文件能够任意抉择起始扇区和大小(Count sectors)，下图为重组后的raid5磁盘阵列。 数据验证：RAID5磁盘阵列重建实现后由用户方工程师进行验证，通过重复验证确认复原数据残缺无效，本次数据恢复工作实现。

数据库数据恢复环境：5块磁盘组建RAID5，划分LUN供windows服务器应用；windows服务器上部署Sql Server数据库；操作系统层面划分了三个逻辑分区。 数据库故障&初检：未知起因导致Sql Server数据库文件失落，波及到数个数据库和数千张表，不能确定数据存储地位。数据库文件失落后服务器依然在开机运行，所幸没有大量写入数据。1、将故障服务器内所有硬盘以只读形式进行全盘镜像备份，后续数据分析和数据恢复操作都基于镜像文件进行，防止在复原数据的过程中对原始数据造成二次毁坏。2、基于镜像文件剖析raid5底层数据，通过剖析获取到的raid相干信息及外部数据块信息重组RAID。重组RAID： 3、实现RAID重组后提取LUN内的三个逻辑分区的镜像。4、扫描文件系统内失落文件，未找到被删除的数据库文件。5、初检后果为数据库文件失落，在文件系统层面无奈复原数据库数据。 数据库数据恢复流程：1、通过初检后发现数据库文件被删除且无奈在文件系统层面进行复原后，北亚企安数据恢复工程师决定通过扫描数据页，提取页内记录的形式来复原失落的数据库数据。2、应用北亚企安自主开发的数据页扫描程序扫描分区内数据页并进行提取。扫描两个分区镜像后发现系统盘分区镜像内的数据页数量极少且数据页断裂情况严重，另一分区内扫描到的数据页数量较多，暂定此分区为数据库文件的存储空间。扫描数据页： 3、Sql Server数据库应用零碎表来治理所有用户表，零碎表内记录了各表的列数、数据类型及束缚信息等。在对系统表进行解析的过程中发现提取进去的数据页内的零碎表损坏，无奈失常读取信息。在与用户方沟通后得悉数据库有备份文件，而且备份实现后也没有对表构造进行过大的改变，零碎表可用。4、还原备份： 5、别离提取须要复原数据的三个库中各表的表构造信息。提取表构造信息： 6、解析表构造脚本，将各表的列信息存入数据库内便于在后续的数据恢复过程中应用。扫描脚本文件： 将表构造信息存入数据库： 7、解析零碎表，获取用户表id信息、关联表构造与数据页。8、新建数据库环境，应用北亚企安自主编写的软件解析记录并导入到环境内。9、整顿复原后果。数据库文件存储的分区内除了寄存数据库文件外还寄存若干备份文件，所以在导出记录后可能存在反复数据，须要去重。由北亚企安数据恢复工程师编写程序进行去重。数据库去重： 10、解决完所有数据后交由用户方验证数据。用户方工程师通过重复查验后确认复原数据残缺无效。将复原进去的数据迁徙到用户方筹备好的存储设备中。

数据库数据恢复环境：某公司存储上部署SQL SERVER数据库，数据库中有1000多个文件，该SQL SERVER数据库每10天生成一个NDF文件，数据库蕴含两个LDF文件。 数据库故障&剖析：存储设备呈现故障导致SQL SERVER数据库异样，通过检测发现有几个ndf文件大小变为0KB。尽管存储故障导致NDF文件大小变为0KB，然而数据恢复工程师揣测NDF文件还存在于磁盘中。能够通过编写数据库扫描碎片程序扫描数据库碎片，通过碎片拼接来复原NDF文件，最初修复数据库。 数据库数据恢复过程：1、将故障存储中所有磁盘以只读形式进行全盘备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止数据恢复过程中可能对原始数据造成的二次毁坏。2、由北亚企安数据恢复工程师编写数据库碎片扫描程序扫描数据库碎片。3、依据NDF文件的页面特色，依照文件号，页号拼接扫描进去的数据库碎片，重组生成出这些0kb的NDF文件。4、应用北亚企安自主开发的MSSQL文件检测工具对所有数据文件进行检测，后果发现拼接出的4个NDF文件有大量的空数据页，其余文件失常。5、进一步剖析存储中损坏的lun，发现这些空数据页在存储层面曾经齐全损坏，无奈复原，即这4个NDF文件不能完全恢复。6、尝试附加数据库，报错 “解决数据库的日志时出错，如果可能请从备份还原。如果没有可用的备份，可能须要从新生成日志”。7、批改零碎表，从零碎表剔除掉最初增加的LDF文件，计算并批改校验。尝试进行无日志附加数据库，报错：“数据库存在一致性谬误”。8、批改零碎表中这4个损坏的NDF文件的块数量，使数据库中记录的文件的块数量和拼接进去的NDF的块数量统一，计算并批改校验值。无日志附加数据库，依然报错“数据库存在一致性谬误”。9、因为空数据页都呈现在这4个NDF文件前面的十几个块中，截断文件对数据完整性影响不大。从新批改零碎表和NDF文件，将数据库中记录NDF块数量的值改至报错的前一页，计算并批改校验。从新进行无日志附加数据库，报错“因为数据库没有齐全敞开，无奈从新生成日志”。10、批改MDF文件中的数据库的状态值，让数据库认为是齐全敞开的。从新附加数据库，附加胜利。 数据库数据验证：数据库文件胜利附加后，用户通过数据库中的对象进行初步查问、验证，通过重复验证后确认表中信息正确，数据残缺可用。本次数据恢复工作实现。

服务器故障环境：HP MSA某型号存储，8块SAS的硬盘组建RAID5磁盘阵列，其中包含1块热备盘。故障存储中基于该RAID组的LUN均调配给HP-Unix小机应用，下层做的LVM逻辑卷，存储的数据为Oracle数据库及OA服务端。 服务器故障：RAID5磁盘阵列中2块磁盘未知起因离线，阵列中的热备盘尽管胜利激活，RAID5磁盘阵列瘫痪，下层LUN不可用。 服务器数据恢复过程：1、因为存储中RAID阵列解体是因为磁盘掉线导致的，拿到磁盘后先由硬件工程师对故障存储中的所有磁盘做物理故障检测，检测后没有发现硬盘存在物理故障。应用坏道检测工具检测磁盘坏道，也没有发现坏道。2、将故障存储中所有硬盘以只读形式做残缺的镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止数据恢复操作可能对原始数据造成二次毁坏。局部备份数据：3、因为故障存储中所有磁盘不存在物理故障，也没有发现坏道，所以磁盘离线起因就是某些磁盘读写不稳固。因为该品牌存储的RAID控制器针对磁盘的检测策略比拟严格，极大可能性把性能不稳固的磁盘认定为坏盘并踢出RAID组。一旦RAID组中掉线的磁盘数量超过该RAID级别容许掉盘的最大数量，这个RAID组就会解体，下层基于RAID组的LUN也将不可用。4、剖析RAID组的信息如条带大小，磁盘程序及数据走向等，而后依据剖析获取到的raid信息重构RAID组。通过剖析发现其中一块盘的数据和其它盘不太一样，初步判断这块盘就是热备盘。剖析其余数据盘（除了热备盘）的底层，搞清楚Oracle数据库页在每个磁盘中散布的状况。5、剖析数据盘中的数据发现有一块硬盘在同一个条带上的数据和其余硬盘不一样，初步判断此盘是先掉线的，通过北亚企安自主开发的RAID校验程序对这个条带做校验，最终确定这块盘就是先掉线的那块硬盘。6、因为LUN是基于RAID组的，将RAID组重构进去之后就开始剖析LUN在RAID组中的分配情况以及LUN调配的数据块MAP。将每一个LUN的数据块散布MAP提取进去，而后针对这些信息编写程序解析所有LUN的数据MAP，而后依据数据MAP导出所有LUN的数据。 7、剖析生成进去的所有LUN，发现所有LUN中均蕴含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息后发现一共有3个LVM：其中1个LVM中划分了一个LV，外面寄存OA服务器端的数据；另外1个LVM中也划分了一个LV，外面寄存长期备份数据；最初1个LVM也只划分了一个LV，外面寄存Oracle数据库文件。北亚企安数据恢复工程师编写LVM解释程序解释每个LVM中的LV卷，但在解释过程中程序出错。8、仔细分析程序报错的起因，由开发工程师debug程序出错的地位，并同时检测复原进去的LUN，检测LMV逻辑卷的信息是否损坏。通过检测发现LVM信息曾经损坏。尝试人工修复损坏的区域，并同步批改LVM解释程序从新解析LVM逻辑卷。9、搭建HP-Unix环境，将解释进去的LV卷映射到HP-Unix并尝试挂载文件系统，后果挂载文件系统出错。尝试应用“fsck –F vxfs” 命令修复vxfs文件系统，修复实现后发现还是不能胜利挂载。狐疑是底层vxfs文件系统的局部元数据曾经毁坏。10、剖析解析进去的LV并依据VXFS文件系统的底层构造校验此文件系统是否残缺。剖析后果发现底层VXFS文件系统有问题，存储设备瘫痪的时候文件系统正在执行IO操作，局部文件系统元文件损坏。北亚企安数据恢复工程师手工修复这些损坏的元文件，直至VXFS文件系统可能被失常解析。11、再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，文件系统胜利挂载。12、在HP-Unix小机上mount文件系统后，将所有用户数据均备份至指定的磁盘空间。局部文件目录：13、应用工具检测每个Oracle数据库文件的完整性，没有发现问题。应用北亚企安自主开发的Oracle数据库检测工具（测验更严格）进行检测，发现有局部Oracle数据库文件和日志文件校验不统一。数据库工程师对这部分文件进行修复并再次校验，直到所有Oracle数据库文件校验通过。14、将复原进去的Oracle数据库附加到原始生产环境的HP-Unix服务器中，启动Oracle数据库胜利。 数据验证：在用户方工程师的配合下，启动Oracle数据库和OA服务端。通过笔记本电脑上装置的OA客户端对最新的数据记录以及历史数据记录进行重复验证，并且安顿用户方公司不同部门人员进行近程验证。最终确认数据无误，残缺可用。本次数据恢复工作实现。

Oracle数据库常见数据劫难：1、ORACLE数据库无奈启动或无奈失常运行。2、ORACLE ASM存储毁坏。3、ORACLE数据库数据文件失落。4、ORACLE数据库数据文件损坏。 5、ORACLE DUMP文件损坏。 Oracle数据库常见数据劫难的数据恢复可能性剖析：1、ORACLE数据库无奈启动或无奈失常运行：这种故障状况下复原oracle数据库数据的可能性十分高。技术层面上，如果SYSTEM表没有损坏，则数据恢复较容易；如果SYSTEM表损坏，则须要北亚企安数据恢复工程师人工核对表构造，复原过程所需工夫较长。 2、ORACLE ASM存储毁坏：ASM重置或组成ASM的成员设施呈现故障，只有呈现故障后无大量新数据写入，数据恢复比拟容易。3、ORACLE数据库数据文件失落：无论是删除、格式化还是未知起因失落，只有没有新的数据写入，不论是什么操作系统，都能够通过ORACLE外部的数据组织规定将ORACLE数据库数据文件复原进去，但可能须要北亚企安数据恢复工程师去人工核查数据文件的名称。4、ORACLE数据库数据文件损坏：如ORACLE数据文件局部损坏(如笼罩)，通过简单的数据提取和重组能够将未损坏局部的数据记录复原进去，并可新建表追加进去，复原过程所需工夫较长。5、ORACLE DUMP文件损坏：如果ORACLE DUMP文件损坏，能够将损坏局部去除，而后将其余局部追加至数据表。 数据安全Tips：1、软件故障：发现数据失落后，尽可能防止再进行任何操作。有时候，即便什么都不做，只有故障设施通电开机也可能导致数据失落的重大状况进一步加剧。如果条件容许，发现问题后马上对磁盘或存储卷做残缺备份。2、硬件故障：在设施无奈工作，尽可能不要再对设施加电，防止设施进一步损坏。 如何升高数据劫难带来的损失？最好的方法无非就是做好备份，尽量采纳多存储备份。如果数据十分重要，可思考进行异地备份。

服务器数据恢复环境：HP StorageWorks存储，10块磁盘组建了raid5磁盘阵列，其中有1块磁盘是热备盘。 服务器故障：raid5磁盘阵列中2块磁盘离线，硬盘指示灯显示黄色。管理员通过初步查看，发现磁盘阵列的磁盘序列号不能读取且无奈通过扩展卡辨认，初步推断离线磁盘呈现物理故障。 服务器数据恢复过程：1、将故障raid5磁盘阵列中的完整磁盘以只读形式做镜像备份，将存在物理故障的离线硬盘进行硬件故障修复后再进行备份，其中一块离线磁盘通过检测后发现损坏重大无奈修复。2、通过重组RAID5磁盘阵列复原数据。a、判断起始扇区。基于镜像文件剖析底层数据发现该raid5磁盘阵列中所有磁盘的0扇区都体现为“55AA”，0x01C2H处显示“05”代表一个扩大分区，该MBR分区不正确。持续查找发现另外1块磁盘中的MBR分区失常（0x01C6处数值代表指向的下一个扇区为GPT的头部），根本能够判定该盘是第一块硬盘，GPT分区所在扇区起始于172032扇区，因而初步确定LUN的起始扇区是172032扇区。b、判断raid阵列stripe(条带)大小。stripe(条带)是raid磁盘阵列中用于数据处理的根本单元，条带的大小受raid磁盘阵列影响。剖析条带大小的根据是raid5磁盘阵列中每一条带组含一个大小与之相等的校验区。北亚企安数据恢复工程师通过查问剖析出该raid5磁盘阵列中的条带大小为1024扇区。c、确定磁盘阵列磁盘盘序。因为曾经剖析该磁盘阵列的条带大小为1024扇区，依照此法则进行宰割，使每一条带与记录大小雷同。将曾经剖析进去的第一块硬盘放在第一位，北亚企安数据恢复工程师通过比照剖析raid5磁盘阵列走向剖析出磁盘阵列的盘序。d、重组RAID阵列。利用下面剖析进去的raid相干信息虚构重组raid5磁盘阵列。4、验证数据。对重组好的磁盘阵列进行数据验证，通过验证没有发现问题。

服务器数据恢复环境：磁盘柜+raid卡+15块磁盘组建一组raid5磁盘阵列，划分2个lun；下层操作系统划分若干分区，通过LVM扩容形式将其中一个分区退出到了root_lv中，其余分区格式化为XFS文件系统。 服务器故障：为服务器重装操作系统时误操作导致分区产生扭转，寄存重要数据的一个分区失落，无法访问。 服务器数据恢复过程：1、对故障服务器中的所有磁盘进行初检没有发现物理故障。将故障服务器中所有硬盘以只读形式残缺镜像到北亚企安备份服务器上。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对数据恢复过程中可能对原始磁盘数据造成的二次毁坏。2、应用北亚企安自主开发的工具查问FILE ID编号。剖析故障服务器中raid5磁盘阵列的盘序、条带大小、循环方向、同异步等raid相干信息，依据剖析获取到的raid相干信息虚构重组raid。3、定位到xfs文件系统分区起始地位。校验xfs文件系统的完整性及正确性后发现xfs文件系统头部的超级块及局部节点、目录项失落。4、依据超级块备份及文件系统中的目录树结构，北亚企安数据恢复工程师修复&还原超级块。修复实现的超级块： 5、修复xfs文件系统中失落的节点及目录项；对失落的节点、目录项进行修补、重构。修复实现的根节点和重做的目录项： 6、修复实现，北亚企安数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。修复实现的目录构造： 7、数据恢复工程师对提取进去的数据进行检测没有发现问题后，将数据交付给用户方亲自进行验证。通过用户方工程师重复验证后，确认复原进去的数据残缺可用，本次数据恢复工作实现。

因为raid的特点和劣势，磁盘阵列技术被广泛应用于服务器和存储等商用畛域。因为用户基数大，呈现故障的状况也不少。通过这篇文章介绍一下常见的raid磁盘阵列数故障类型和起因。 故障类型一、磁盘阵列处于降级状态时未及时rebuild。RAID磁盘阵列的数据安全冗余是利用局部空余空间实现的，阵列中有成员盘下线便无奈持续提供冗余空间。如果此时未能及时更换新磁盘并rebuild整个卷，一旦raid中有其余成员盘离线将会导致整个raid卷无奈工作。这类故障是北亚企安数据恢复工作中会常常遇到case。 故障类型二、raid控制器故障。磁盘阵列控制器在充当着操作系统与物理硬盘之间的连贯纽带。磁盘阵列中的硬盘数量、容量大小、raid级别、校验形式等raid信息有的存储于硬盘，有的存储于阵列卡或者在二者中都有存储。如果控制器呈现故障，raid信息就无奈还原，如果呈现这种故障，即便可能还原raid构造并再次重建raid阵列也无奈复原数据。 故障类型三、固件算法缺点。RAID的创立、重建、降级、爱护等性能的实现依附的raid固件上的一套非常复杂的算法，任何简单的算法都会有BUG，只管厂商不会轻易抵赖自家产品固件算法的BUG（有可能本人也不晓得）。因为固件算法BUG，产生无法解释的故障可能性必定是有的。比方在北亚企安接到的数据恢复case中就遇到过晚期生产的某品牌服务器RAID中一块盘OFFLINE后，故障盘与报警灯不统一的状况。用户在更换故障盘进行REBUILD时被误导拔错盘，导致整个RAID解体。 故障类型四、IO通道碰壁导致RAID掉盘。RAID控制器在设计时候优先思考的是数据的安全性，RAID会尽可能防止将数据写到不稳固的存储介质上。当控制器与物理盘进行IO时，如果工夫超过某个阈值或校验关系不满足，RAID控制器便会认为对应的存储介质已不具备继续稳固工作的能力并让其强制下线，而后告诉管理员尽快解决问题。这种设计的初衷从技术上和逻辑上来看没有问题，但对于如物理连贯线路松动，硬盘工作反馈超时（硬盘还是完整的）等场景来说，控制器无奈分辨存储介质是否真的呈现物理故障，这种状况下会大概率强制磁盘下线。这类故障产生概率比拟高且无奈防止，很多用户因而类故障质疑服务器厂商。实际上。越是设计平安的RAID控制器，越容易产生此类故障。 故障类型五、控制器的稳定性。RAID的控制器在ONLINE状态下(无离线盘)工作是最稳固的。当局部硬盘（物理故障或者逻辑故障）离线后控制器便会工作在一个绝对不稳固的状态，这也是好多中低端的RAID控制器在有磁盘离线后就体现出读写性能降落的起因。控制器的不稳固会减少数据吞吐时IO滞留的可能性，从而导致上述第四个类型的故障的产生。中低端的控制器（无高性能解决芯片或者大容量高速缓存）产生这类故障的概率要高得多。 故障类型六、阵列中硬盘故障。很多人认为磁盘阵列只有在失常工作，阵列中就不会存在有物理故障的硬盘。这个观点的判断根据是一旦raid中有硬盘呈现物理故障，阵列控制器就会将故障硬盘踢下线。然而实际上并非如此。RAID很少会读取到物理硬盘的所有磁盘空间，同一时间更是不可能。局部状况下，硬盘会在RAID没有读取到的区域或者RAID以前读取过的区域呈现坏道，这类坏道因为没有被RAID读过，所以在控制器来看还是好的。呈现这种状况后可能会产生的间接结果就是在REBUILD过程中，当一块物理硬盘离线后，在进行REBUILD过程中，如果其余硬盘存在这类没有被RAID读取到的坏道，因为REBUILD是对全盘做全面同步，在REBUILD过程中就肯定会读写到这类之前没有被RAID读取到的坏道。这时REBUILD还没实现，新盘无奈上线，又在旧盘发现了坏道，RAID极有可能将发现坏道的旧盘踢出，这样就会导致RAID故障。 故障类型七、人为误操作。人为误操作导致的RAID故障，例如：误拔了RAID里的硬盘、更换坏盘不及时、插入硬盘更换或者进行其余操作后遗记硬盘在RAID中的程序、不小心删除了原RAID配置等。

服务器数据恢复环境：IBM Storwize某型号存储，共10块磁盘，组建了2组Mdisk退出到一个存储池中，创立了一个通用卷存放数据，寄存的数据蕴含oracle数据库。 服务器故障：存储中其中一组Mdisk有两块磁盘呈现故障离线，该组Mdisk生效，通用卷不可用。 服务器数据恢复过程：一、对故障离线的两块硬盘做物理故障检测，发现盘片有划伤且无奈做镜像。将故障存储中其余磁盘以只读形式做全盘镜像, 后续的数据分析和数据恢复操作基于镜像盘进行。防止在复原数据的过程中对磁盘中的原始数据造成二次毁坏。 二、组建raid。因为故障存储的构造比较复杂，在数据恢复过程中须要屡次组建raid磁盘阵列。1、依据用户方提供的配置信息将磁盘依照Mdisk组分类。剖析每一组Mdisk中的硬盘获取raid相干信息。利用获取到的raid相干信息虚构重组Mdisk。2、通过剖析Mdisk获取到pool存储池的相干信息并虚构重组pool存储池，提取Lun的数据。 三、复原数据库。实现LUN的数据提取后，依据固有特征值扫描oracle数据库数据页，共失去4个文件：SYSTEM、SYSAUX、USER、UNDOTBS1。1、尝试解析零碎表，发现零碎表损坏重大，很多表的信息失落，零碎表不可用。在零碎表不能用的状况下，北亚企安数据恢复工程师通过人工匹配表构造信息和记录特色信息来确定数据页所属表。2、因为人工匹配成果不现实，于是尝试用匹配非凡记录进行匹配。匹配到后果后，北亚企安数据恢复工程师手工解析记录，查看是否合乎表构造、语义要求及类型要求。通过长时间的搜寻、解析、匹配工作后，最终实现数据页到表的连贯。3、提取备份库内表构造，创立复原环境。应用北亚企安自主编写的记录提取程序提取数据页内记录，并导入到复原环境内。5、导入实现后查看是否有反复、谬误数据，发现立刻解决直至没有发现任何问题后导出数据并由用户方亲自进行验证。6、通过用户方工程师的重复验证，确认复原进去的数据残缺无效。本次数据恢复工作实现。因为故障存储中有两块盘的盘片有划伤，在缺失两块盘的状况下，数据呈现条带化谬误，工程师尝试了各种办法才修复了谬误并提取出用户所须要的数据库数据。

服务器数据恢复环境：DELL EqualLogic PS系列某型号存储；16块SAS硬盘组成一组RAID5；划分了4个卷，采纳VMFS文件系统，寄存虚拟机文件。 服务器故障：存储设备中磁盘呈现故障导致存储不可用，且存储设备曾经过保，用户方分割到咱们数据恢复核心要求复原该存储设备中的数据。 服务器数据恢复过程：1、由硬件工程师为存储设备中的16块磁盘做硬件故障故障检测，通过检测发现其中的2块磁盘存在坏道，且SMART谬误冗余级别曾经超过阈值。将另外14块没有发现物理故障和坏道的硬盘以只读形式进行全盘镜像。对于2块有坏道的硬盘，由硬件工程师修复后应用业余工具做镜像。 2、故障存储上有两块盘的指示灯显示黄色，剖析收集到的存储日志信息，找到两块硬盘的掉线工夫，确定数据最新的那块硬盘，用数据最新的硬盘进行数据恢复。 3、基于镜像文件剖析raid相干信息，依据剖析获取到的raid信息虚构重构raid。4、依据位图信息在重构的RAID中将4个lun全副提取进去。5、依据剖析底层构造，北亚企安数据恢复工程师将4个VMFS文件系统进行跨区卷组合，导出用户数据，并验证虚拟机是否失常。 数据验证：将卷里的文件都拷贝进去，通过网络共享的形式验证复原进去的虚拟机，虚拟机都能够失常启动。将虚拟机文件移交给用户方，通过用户方工程师的重复验证，确认复原进去的数据残缺无效。通过漫长的底层剖析，加上一直的测试，历时7天实现数据恢复工作。

数据库数据恢复环境：Windows Server操作系统服务器，部署MongoDB数据库。 数据库故障&剖析：在MongoDB数据库服务未敞开的状况下，管理员将MongoDB数据库文件从原分区拷贝到其余分区，而后将MongoDB数据库所在原分区格式化，格式化实现又将MongoDB数据库文件拷回原分区，启动MongoDB服务失败并报错。 在MongoDB数据库服务没有敞开的状况下，间接拷贝MongoDB数据库文件，mongod.lock和WiredTiger.lock这2个文件拷贝进去是有问题的。正确的操作方法是：在拷贝出的数据库文件中将这两个文件删除后再次启动服务，这2个文件会由MongoDB自行从新生成。通过检测拷贝出的MongoDB数据库文件发现_mdb_catalog.wt文件失落。_mdb_catalog.wt文件里存储了MongoDB数据库中所有汇合的元数据，MongoDB数据库启动时须要从_mdb_catalog.wt文件中读取相干信息。如果_mdb_catalog.wt文件失落，MongoDB数据库就无奈获取数据库中汇合对应的名字、汇合的创立选项、汇合的索引信息等元数据，数据库无奈启动。 数据库数据恢复过程：1、对MongoDB数据库所波及的硬盘以只读形式进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止在复原数据的过程中对原始数据造成二次毁坏。2、尝试从文件系统的层面复原_mdb_catalog.wt文件。扫描数据库分区没有发现和_mdb_catalog.wt文件相干的信息。依据MongoDB数据库数据文件的特征值扫描数据库分区，也没有发现和_mdb_catalog.wt相干的数据区域。所以能够判定_mdb_catalog.wt文件曾经被彻底毁坏，无奈复原，只能从数据库层面复原数据了。3、该案例中部署的MongoDB数据库基于WT存储引擎，能够应用WT实用工具包提取数据库中的数据。下载WT实用工具包并在windows环境下编译出可执行的wt工具。 4、编译实现后，北亚企安数据恢复工程师应用wt工具荡涤数据库的汇合文件中的数据，实现荡涤后间接读取文件中的数据并写入到一个dump文件中。将数据库的各个汇合文件中的全副可用数据提取进去。5、创立一个MongoDB数据库，依据提取出的汇合文件创建对应数量的空集合。应用wt工具将提取进去的dump文件一一写入到新创建的空集合中。6、通过查问汇合中的数据来确认这些写入dump文件的汇合与元数据库中汇合的对应关系，批改汇合名称并重建索引信息。7、通过查问汇合中的记录，确定记录类型。确定fs.files和fs.chunks汇合的地位后，批改这两个汇合名称为xxx.files和xxx.chunks后并重建汇合索引，汇合复原实现后就能够失常查看其中数据。 数据库数据验证：帮助用户方工程师对全副汇合进行索引重建之后，由用户对数据库进行查问验证，确认数据无误，本次数据恢复工作实现。

服务器数据恢复环境：昆腾系列存储：9个配置24块硬盘的磁盘柜。8个磁盘柜存储数据，1个磁盘柜存储元数据。元数据磁盘柜有24块硬盘，组建了8组RAID1阵列+1组4盘位RAID10阵列+4个全局热备盘。数据磁盘柜组建了32组6盘RAID5阵列。这32组RAID阵列分为2个存储系统。存储及文件系统架构大抵如下：注：Meta_LUN(元数据卷) Data_LUN（用户数据卷） 服务器故障：数据磁盘柜其中1个存储系统中的一组RAID5的2块磁盘先后故障离线，该RAID5阵列生效，导致整个存储系统无奈应用。 服务器数据恢复过程：1、将故障存储中所有硬盘以只读形式做残缺镜像备份，备份实现后将硬盘依照原样还原到存储柜中。后续数据分析和数据恢复操作都基于镜像文件进行，防止在数据恢复过程中可能对原始数据造成的二次毁坏。 2、在镜像过程中发现故障RAID5中的1块离线硬盘存在大量坏道区域，无奈失常备份。由硬件工程师将该故障盘收盘更换固件，而后应用业余工具进行修复，通过一番解决后该硬盘能够持续备份，但坏道仍然存在。局部镜像文件截图： 3、基于镜像文件对故障RAID5阵列进行剖析，获取到RAID相干信息，依据获取到的RAID相干信息虚构重组RAID阵列，并将RAID中的LUN导出为镜像文件。在剖析过程中发现，损坏较重大的硬盘为后离线的硬盘。4、登录昆腾存储的治理界面，获取到StorNext文件系统中卷相干的一些根本信息。卷相干信息截图： 剖析StorNext文件系统中的Meta卷和Data卷，该环境中的StorNext文件系统蕴含2个Data卷，每一个残缺的Data卷是由多组RAID中的LUN组成的。通过剖析这些LUN失去LUN之间组合的算法法则，虚构重组出残缺的Data卷。 5、剖析Meta卷中的节点信息和目录项信息，以及Meta卷和Data卷之间的对应关系。依据一个Meta卷治理多个Data卷的状况，北亚企安数据恢复工程师钻研出Meta卷到Data卷的索引算法。文件节点： 目录块： 6、依据后面步骤获取到的数据恢复所需全副信息，北亚企安数据恢复工程师编写程序，扫描Meta卷中的节点信息和目录项信息，解析目录项和节点，获取残缺的文件系统目录构造，解析每一个节点中的指针信息，并将这些信息记录在数据库中。文件信息： 7、北亚企安数据恢复工程师编写文件提取程序读取数据库，依据解析出的信息以及两个Data卷之间的聚合算法提取数据。数据恢复工程师对提取进去的数据进行检测，没有发现问题。 8、将全副文件提取到本地，移交给用户方进行检测。通过用户方工程师重复检测后，用户方对复原后果称心。本次数据恢复工作实现。

服务器数据恢复环境：HP-EVA存储环境：EVA某型号控制器+EVA扩大柜+FC硬盘。 服务器故障：EVA存储中两块磁盘掉线导致存储中某些LUN失落不可用。 服务器数据恢复过程：1、首先对故障存储中所有磁盘做物理故障检测，通过检测没有发现有硬盘存在物理故障。应用坏道检测工具检测也没有发现坏道，磁盘坏道检测日志局部截图：2、将故障存储中所有磁盘以只读形式做残缺镜像备份，以防后续数据恢复过程中操作不当对原始数据造成二次毁坏。局部备份数据如下：3、因为所有磁盘没有发现物理故障或者坏道，能够判断硬盘掉线是因为磁盘读写不稳固导致的。EVA控制器对磁盘的检测策略十分严格，EVA控制器会认为性能不稳固的磁盘是坏盘，将认为是坏盘的磁盘踢出磁盘组。如果某个LUN的同一个条带中掉线的磁盘达到极限，这个LUN将不可用，即如果EVA存储中所有的LUN都蕴含这些掉线的盘，所有LUN都会受影响，所以两块磁盘掉线也会导致整个存储的LUN都不可用。目前的状况是现存8个LUN，损坏7个LUN，失落6个LUN，须要复原存储中所有LUN的数据。4、HP-EVA的LUN都是以RAID条目标模式来存储数据的，EVA将每个磁盘的不同块组成一个RAID条目，RAID条目标类型能够有很多种。须要剖析出组成LUN的RAID条目类型和这个RAID条目是由哪些盘的哪些块组成。这些信息都寄存在LUN_MAP中，每个LUN都有一份LUN_MAP。EVA将LUN_MAP别离寄存在不同的磁盘中，应用一个索引来指定其地位。因而去每个磁盘中找到这个指向LUN_MAP的索引就能够找到现存LUN的信息。5、尽管磁盘中记录了指向LUN_MAP的索引，然而它只记录现存的LUN，失落的LUN是不会被记录索引的。因为EVA中删除一个LUN只会革除这个LUN的索引，并不会革除这个LUN的LUN_MAP。所以只须要扫描所有磁盘，找到所有合乎LUN_MAP的数据块，排除现有的LUN_MAP，剩下的LUN_MAP也不肯定全是删除的，也有一些可能是旧的。这种状况下是无奈在LUN_MAP中筛选的，只能先将所有LUN_MAP的数据都复原进去，人工去核查哪些LUN是删除的。6、掉线磁盘中寄存的是一些旧的数据，在生成数据的时候须要将这些磁盘都排除掉，提取数据之前须要把这些掉线磁盘找到。因为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如下： 数据验证：用户方工程师对复原进去的数据进行测验，通过重复验证后确认数据残缺可用，本次数据恢复工作实现。 EVA存储数据安全Tip：1、常常巡视机房设备，发现报警信息及时处理。2、操作存储时要审慎，防止误操作导致数据失落。3、如果发现EVA控制器局部模块不稳固，应及时更换。4、因为EVA存储故障多是由磁盘不稳固导致的，EVA存储内的磁盘应该是同一批次的磁盘。因而，没有掉线的磁盘性能也快到极限，如有条件倡议一起更换这批磁盘。

服务器数据恢复环境：NetApp某型号存储，共96块SAS硬盘，划分的lun都映射给小型机应用，寄存的是Oracle数据库文件，采纳ASM裸设施存储形式。 服务器故障：管理员误操作删除了该NetApp存储上的所有lun。具体情况是：工作人员给NetApp存储设备从新划分空间，间接把存储的卷全副删除并进行重新分配。在删除所有卷后还没有来得及调配的时候，下层业务就出现异常。运维工程师紧急排查故障状况，发现业务服务器上的磁盘都不见了，无法访问数据。 服务器数据恢复过程：1、为了预防在数据恢复过程中可能对原始磁盘数据造成的二次毁坏，将该NetApp存储上的每块磁盘以只读形式做残缺镜像。后续所有的数据分析和数据恢复操作都在镜像文件上进行。2、基于镜像文件剖析Netapp存储数据。a、剖析盘序和LVM的组成形式；b、扫描硬盘内的所有节点，个别只扫描“MBFI”。c、在节点扫描后果中找到文件大小合乎需要的节点并提取此节点uid，并判断索引根。d、依据索引根内的第一级数据指针提取本文件的所有间接数据指针（须要参考节点中0x03地位的MAP深度。为0x00时间接从节点内提取数据，为0x01时须要提取一次MAP，为0x02时须要提取两次MAP......）。在指针提取结束后开始提取文件数据。3、解析超级块。在硬盘的后面扇区的地位找到超级块相干信息，从超级块中获取到磁盘组名字、磁盘组的逻辑起始块号、总块数、磁盘组中raid的编号。netapp超级块信息：4、剔除校验盘。每个数据块占8个扇区，数据块后附加64字节数据块形容信息。依据这些信息能够判断出作为校验盘（提取数据时校验盘需剔除）的磁盘。校验块形容信息：5、判断aggr盘。确定各个磁盘所属aggr组，而后判断组内盘序（根据每块磁盘8号扇区的磁盘信息以及磁盘开端的RAID盘序表确定盘序）。数据指针跳转时不思考校验盘，所以只获得数据盘的盘序即可。netapp盘序表：6、剖析节点及节点头部信息。Netapp的节点散布在数量泛滥的数据块内，在数据块内又被对立组织为节点组。每个节点组的前半部分字节记录零碎数据，后半局部字节记录各个文件节点。依据用户级别可将节点分为两类：“MBFP”系统文件节点和“MBFI”用户文件节点，在数据恢复时个别只取MBFI节点组即可。netapp节点样：7、获取目录项，并依据目录项节点编号找到对应节点。目录项信息：8、剖析出该Netapp存储构造后，用北亚企安自研的NetApp解析程序解析asm文件系统，提取出oracle数据库文件。9、搭建小机环境并装置oracle数据库，检测提取进去的数据库文件和备份文件。10、应用提取出的数据库文件启动oracle数据库，启动失常。11、应用最新的数据库备份文件还原数据库，而后由用户方亲自进行验证，通过重复验证，用户方确认复原进去的oracle数据库数据残缺可用，数据恢复工作实现。

服务器数据恢复环境：Linux零碎服务器，EXT4文件系统，部署KVM虚拟机。 服务器故障：服务器上的KVM虚拟机被误操作删除，每台虚拟机蕴含一个qcow2格局的磁盘文件和一个raw格局的磁盘文件，须要复原raw格局的磁盘文件，虚拟机外面寄存的是数据库和程序代码。 服务器数据恢复过程：1、对服务器上所有磁盘以只读形式进行全盘备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析EXT4文件系统，定位被删除虚拟机磁盘文件的节点地位。3、获取磁盘文件残留的索引信息，校验残留索引信息的正确性，北亚企安数据恢复工程师手动修复毁坏不重大的索引。获取的索引等信息：4、索引修复实现后，解析残留的各级索引，从虚拟机所在的卷中提取虚构磁盘文件并校验提取出的磁盘文件的正确性与完整性。5、依据虚构磁盘文件的提取状况，获取卷中未被索引到的自由空间。6、从自由空间中获取无效信息，北亚企安数据恢复工程师尝试修补虚构磁盘文件（如节点，目录项，数据库页等信息）。提取出的自由空间： 数据恢复后果：1、因为索引失落，提取出的虚构磁盘文件并不残缺，有局部数据库文件失落，能够从自由空间中获取数据库页对数据库文件进行修补，但因为局部页所在区域被笼罩占用，只能尽量多的去补页。2、对于寄存程序代码的服务器中文件的节点和目录项失落的状况，若节点或目录项有残留，能够尝试补齐节点和目录项。但如果有文件的节点和目录项同时失落，这种状况无奈补齐。3、程序代码文件不具规律性，若其数据区失落，也无奈补齐。复原出的局部目录构造： 数据验证：对虚构磁盘文件及其中的数据库文件尽最大致力修补后，交由用户方工程师验证。通过重复验证，发现有小局部不重要的数据失落，确认数据恢复后果无效。

服务器数据恢复环境：EMC某型号存储，20块磁盘组建raid5磁盘阵列，划分2个lun。 服务器故障：管理员执行重装系统操作后发现分区产生扭转，原先的sdc3分区失落，该分区采纳xfs文件系统，存储了公司重要业务信息，急需复原该分区数据。 服务器数据恢复过程：1、将故障存储中所有磁盘编号后取出，将所有硬盘数据以只读形式残缺镜像备份到北亚企安的备份服务器上，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据可能造成的二次毁坏。2、基于镜像文件剖析故障存储上的raid5磁盘阵列盘序、条带大小等raid相干信息。通过剖析获取到的raid信息虚构重组出raid5磁盘阵列。3、实现重组raid5后，定位到xfs文件系统的分区起始地位。XFS INODE number：变长的位数示意，由三局部组成：起始块组号＋起始块号＋块内INODE号。起始块号与块内INODE号的位长由SUPERBLOCK中参数指定。3、校验xfs文件系统的完整性及正确性后发现该xfs文件系统头部的超级块及局部节点、目录项失落。4、依据超级块备份及xfs文件系统的目录树结构，北亚企安数据恢复工程师修复还原超级块。5、修补&重构失落的节点、目录项。6、修复实现后由北亚企安数据恢复工程师编写程序解析该xfs文件系统并提取其中的数据。7、由工程师对提取进去的数据进行验证无误后交由用户方工程师检测，通过重复验证确认数据残缺可用，本次数据恢复工作实现。 服务器数据恢复总结：因为本案例中失落分区的文件系统头部的超级块及局部节点、目录项失落。依据超级块备份及XFS文件系统中的目录树结构，对超级块进行修复还原，对失落的节点、目录项进行修补、重构之后，XFS文件系统就能够残缺复原。因为数据失落之后用户方没有对存储做任何写入操作，所以数据及文件系统信息绝大部分保留下来，数据得以完全恢复。

服务器数据恢复环境&故障：误操作格式化服务器RAID5磁盘阵列下的分区（NTFS文件系统）。 服务器数据恢复过程：1、将故障服务器连贯到北亚企安备份服务器上，将故障服务器的所有硬盘设置为脱机状态，而后以只读形式对故障服务器中所有磁盘做残缺备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析出故障服务器的分区大小和扇区数量。依据RAID5的计算模式，应用扇区数除以服务器中理论硬盘（不包含校验盘）的数量失去一个扇区数。3、定位到磁盘备份文件的扇区，在这个扇区的左近查找到另一个GPT分区表，这样就能够查看分区大小。例如：一组6盘raid5阵列的分区大小为1048309759扇区，计算时就应该用1048309759除以5等于209661951扇区。如下图所示(GPT分区表，标记项前8个字节为分区起始扇区，之后8个字节为分区完结扇区，单位512字节/扇区，64bit)： 4、基于镜像文件剖析raid5相干信息，以备重组raid5。5、复原NTFS文件系统下的数据只须要找到分区的文件记录项，依据NTFS文件系统中的MFT程序查看raid5的条带大小和raid走向。 6、依据下面剖析进去的RAID相干信息重组RAID，重组实现后发现有局部文件目录构造失落，不过数据能够复原进去，文件目录失落的状况如下图： 服务器数据恢复总结：NTFS文件系统的分区被格式化对数据的影响并不是很大，数据保留的比拟残缺，复原的几率较大，但可能会遇到局部文件目录构造失落的状况。NTFS文件系统的分区被格式化后尽管能够对失落的数据进行复原，然而也有肯定的危险。强烈建议对服务器和存储设备中数据增强备份，尽可能的防止因为误操作导致服务器数据失落的状况产生。

服务器数据恢复环境：IBM某型号服务器中6块硬盘搭建的raid5磁盘阵列，其中1块盘作为热备盘应用。下层部署的是SAP利用+Oracle数据库。 服务器故障&检测：服务器中RAID5磁盘阵列中的1块盘呈现故障离线，热备盘激活替换离线硬盘，在进行数据同步的过程中又有一块硬盘故障离线，RAID5磁盘阵列瘫痪，下层LUN不可用，服务器解体。IBM服务器中的LUN是基于RAID组的。剖析故障raid5中的所有硬盘，发现其中一块盘的数据同其它盘有显著不同，初步判断这块盘就是HotSpare盘。剖析其余盘以及Oracle数据库页在每个磁盘中的散布状况，获取到该RAID5的条带大小、磁盘程序及数据走向等RAID相干信息。利用获取到的raid相干信息虚构重构RAID5，而后剖析LUN在RAID5中的分配情况以及LUN调配的数据块MAP。只须要将LUN的数据块散布MAP提取进去，针对这些信息编写相应的程序，解析LUN的数据MAP，而后依据数据MAP导出LUN的数据即可复原数据。 服务器数据恢复过程：一、复原Oracle数据库数据。1、将蕴含Oracle数据库数据的LUN进行JFS2文件系统解析，人工修复文件系统的不残缺局部。2、利用北亚企安自主开发的JFS2文件系统解析工具解析修复实现的LUN，而后复原文件系统中所有的Oracle数据库文件。3、检测Oracle数据库文件的完整性。针对检测有坏块的数据库文件，通过扫描所有硬盘找到所有Oracle碎片，组合扫描到的数据页，人工将有坏块的数据库文件修复残缺。4、复原完所有Oracle数据库之后，发现SAP利用还是无奈失常应用。通过剖析发现SAP利用的一些重要数据也是寄存在损坏的存储中，如果没有这些重要的数据，即便在Oracle数据库残缺的状况下SAP利用也无奈失常应用。 二、复原SAP利用数据。1、对复原进去的所有LUN都进行文件系统解析，将蕴含SAP利用数据的LUN进行文件系统的一致性检测。人工修复文件系统不残缺局部，直至复原出所有SAP及SAP Test的数据。2、检测复原进去的SAP利用数据，对损坏的SAP利用数据进行修复，直至所有SAP数据都残缺，只有这样能力保障SAP利用可能失常应用。3、SAP数据修复实现后，联合之前复原进去的Oracle数据库，即可启动SAP利用了。 三、启动并修复Oracle数据库及SAP利用1、启动数据库并修复。把复原的Oracle数据库文件还原到已搭建好的环境中，并尝试启动Oracle数据库。在启动过程中因为数据库一些临时文件的校验不统一导致数据库启动失败。分割Oracle数据库工程师对数据库进行修复，修复实现后Oracle数据库启动胜利，通过重复验证确认数据库中的所有用户及所有表均残缺，而后尝试启动SAP。2、启动SAP并修复。将复原进去的SAP数据还原到已搭建好的环境中并启动SAP，SAP启动失常，但SAP中的用户权限及应用异样，SAP体现为没有序列号。北亚企安数据恢复工程师初步判断是因为SAP的注册文件没有复原进去。从新检测复原过程，排查可能忽略的中央，后果发现的确因为文件系统损坏导致某些文件没有复原进去。从新修复文件系统并复原这些数据，而后启动并查看SAP，后果一切正常。3、在用户方工程师配合下启动服务器内的Oracle数据库和SAP，通过SAP客户端重复验证SAP中所有的数据，没有发现任何问题，复原进去的数据残缺可用。本次数据恢复工作实现。

数据库数据恢复环境：5块硬盘组建RAID5，划分LUN供windows服务器应用，共有三个逻辑分区；在windows服务器内部署有Sql Server数据库。 数据库故障：未知起因导致数据库文件失落，波及5个数据库，数千个表，不能确定数据存储地位。数据库文件失落后服务器仍在运行，但未写入大量数据。 数据库数据恢复过程：1、对故障设施中所有硬盘以只读形式进行残缺镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析raid5，获取raid相干信息并利用信息及外部数据块信息重组RAID。重组RAID：3、提取LUN内的三个分区镜像。4、扫描文件系统内失落的文件，未找到被删除的数据库文件，通过文件系统层面无奈复原数据库数据。5、通过北亚企安数据恢复工程师团队的会诊，最终敲定通过扫描数据页并提取页内记录的数据恢复计划来复原数据库数据。6、应用北亚企安自主编写的数据页扫描程序扫描分区内数据页并进行提取。在别离扫描两个分区镜像后发现零碎盘内数据页数量极少且数据页断裂情况严重；另一分区内扫描到数据页数量较多，暂定此分区为数据库文件存储空间。扫描数据页：7、Sql Server数据库应用零碎表来治理所有用户表，在这些零碎表内记录了各表的列数、数据类型及束缚信息等。解析Sql Server零碎表过程中发现提取出的数据页内零碎表损坏，无奈失常读取信息。与用户方沟通后得悉有备份文件，且备份后没有进行过大的表构造改变，零碎表可用。8、还原备份。还原备份：9、提取数据库中各表的表构造信息。提取表构造信息：10、解析表构造脚本。将各表的列信息存入数据库内。扫描脚本文件:表构造信息存入数据库:11、解析零碎表获取用户表id信息、关联表构造与数据页。12、新建数据库，应用北亚企安自主编写软件解析记录并导入到复原环境内。13、整顿复原后果。在此分区内除了寄存数据库文件外还寄存一些备份文件，所以在导出记录后可能存在反复数据，北亚企安数据恢复工程师编写程序进行去重。数据库去重:14、去重后由用户方工程师进行对复原进去的数据库文件进行检测验证，通过认真查验后确认数据残缺可用。15、由数据恢复工程师帮助用户方工程师将复原进去的数据迁徙到筹备好的环境中。

服务器数据恢复环境&故障：某企业一台存储设备，一组由16块硬盘组建的raid5磁盘阵列。管理员在巡检过程中发现该存储的卷无奈挂载，通过查看发现存储设备的raid5磁盘阵列中有2块硬盘离线。 服务器数据恢复过程：1、查看该存储以后状态，通过storage manager将存储的日志状态备份。2、将存储设备内所有硬盘编号后取出。将所有硬盘挂载到Windows零碎环境下，更改硬盘状态为“脱机”，将所有硬盘进行扇区级的镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。3、基于镜像文件进行剖析后发现raid5磁盘阵列中的1号硬盘、10号硬盘、13号硬盘均存在大量不规则坏道。4、依据坏道列表，北亚企安数据恢复工程师定位到指标镜像文件进行剖析，发现一些EXT3文件系统的关键性数据信息被毁坏，无奈间接通过镜像文件复原数据，只能通过同一条带进行XOR并依据ext3文件系统的文件构造手动修复被毁坏信息的计划来复原数据。5、剖析文件系统的日志文件获取到这台存储的raid5磁盘阵列的所有磁盘的盘序，raid块大小，raid的校验走向等raid信息，依据获取到的raid信息虚构重组raid磁盘阵列。6、重组实现后解析文件系统。因为存储中的次要数据为oracle数据库，能够通过提取dmp文件来复原数据库数据。通过一番致力（oracle数据库数据恢复过程比拟长，这里略过），数据恢复工程师提取出dmp文件，导入验证没有发现任何问题，本次数据恢复工作实现。

服务器数据恢复环境：某公司网站服务器，6块SCSI硬盘组建raid5磁盘阵列；服务器下层：linux操作系统+EXT3文件系统。 服务器故障&剖析：服务器在工作状态下raid5磁盘阵列中的一块硬盘因为未知起因离线。因为raid5中的一块硬盘掉线并不会影响磁盘阵列的失常工作，服务器没有出现异常，直到该raid5磁盘阵列中又有一块硬盘掉线，服务器瘫痪。管理员发现服务故障后，对raid5磁盘阵列进行了查看，然而不能确定这两块硬盘的离线程序，抱着碰运气的想法抉择了其中一块离线硬盘尝试强制上线操作。将这块硬盘强制上线后发现操作系统启动时出现异常，为了防止再次对数据造成毁坏，管理员将服务器关机，之后没有进行任何操作。在过来十多年中，北亚企安数据恢复工程师们常常遇到相似的raid5故障：因为发现不及时或者第一块硬盘掉线时不在意并没有及时处理，当第二块硬盘甚至更多的硬盘掉线时，磁盘阵列彻底解体。第二块磁盘掉线后对后离线的硬盘进行强制上线具备肯定的可操作性行，然而也有很大的危险。强制上线最好由经验丰富的管理员或者数据恢复工程师进行操作，而且强制上线之前必须做好备份工作。这个案例就是管理员在没有备份，也没有搞清楚硬盘离线程序的状况下进行了强制上线操作，最终导致数据失落，服务器解体。 服务器数据恢复过程：1、将故障服务器内的所有硬盘编号后取出，以只读形式对所有硬盘进行镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、在镜像过程中发现除了曾经掉线的两块硬盘外，其余没有掉线硬盘存在坏道，因为这些硬盘没有离线所以临时没有进行非凡解决。3、备份实现后基于镜像文件剖析原raid5磁盘阵列的组成构造并虚构重构raid5环境。4、因为管理员对磁盘阵列进行过强制上线的操作，该操作毁坏了局部数据结构。5、验证raid5构造后由北亚企安数据恢复工程师手工修复被毁坏的那局部构造，导出磁盘阵列内的所有数据。通过数据恢复工程师和管理员的验证，确认复原进去的数据残缺无效。6、在数据恢复工程师的帮助下，管理员在筹备好的服务器环境上从新搭建磁盘阵列并迁徙数据。 服务器数据恢复Tip：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器磁盘阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。4、当服务器因为未知起因的故障而导致系统解体或者文件不辨认/不可用时，通常不倡议自觉地在服务器上进行数据分析和数据恢复操作。如果的确对本人的数据恢复技术有自信，必须先对原服务器的所有硬盘数据进行镜像备份，数据分析和数据恢复操作只能在镜像文件上进行，防止操作失误毁坏原始数据，让后续的数据恢复难度减少。

服务器数据恢复环境&故障：某公司一台存储设备寄存公司外部重要文件。存储设备上有一组由6块硬盘组成的raid5磁盘阵列。存储设备在失常运行过程中忽然解体，管理员强制重启后无奈找到存储设备，屡次重启后还是找不到存储设备。 服务器故障剖析：通过数据恢复工程师和硬件工程师团队的检测和剖析，初步判断这台存储设备故障起因应该是raid模块损坏。raid模块损坏故障包含raid信息失落和raid模块硬件损坏。基于以往大量的案例教训，北亚企安数据恢复工程师团队判断该存储设备故障极有可能就是设施屡次异样断电导致的。通过与用户方管理员的沟通得悉这台存储在呈现故障之前的确遭逢过数次非正常的断电关机，但每次断电后重启一切正常，因而未引起管理员的留神。即便存储设备解体后也没有意识到这次故障与以前设施屡次异样断电有关系。 服务器数据恢复过程：1、由硬件工程师对故障存储中所有硬盘做物理故障检测，通过检测没有发现所有硬盘都能够失常读取，不存在物理故障。2、将所有硬盘以只读形式做残缺镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止在数据恢复过程中对原始数据造成二次毁坏。3、基于镜像文件剖析故障存储中的raid5磁盘阵列的raid构造，获取所有硬盘在阵列中的盘序、校验形式和数据块大小等raid相干信息。利用这些raid相干从新构建一组raid5阵列。4、对重构的raid5阵列进行逻辑校验，逻辑校验胜利后让用户方工程师亲自进行数据验证。5、通过用户方工程师的重复验证，没有发现任何问题，确认复原进去的数据残缺可用，用户方对数据恢复后果十分满意，本次数据恢复工作实现。 服务器数据安全Tips：1、服务器和存储设备所在的机房应该尽量保障电源供给的稳固，如果有设施的确须要关机，肯定要应用正确的关机办法关机，而不是间接断电。2、应用年限比拟长的一些老设施要常常查看，尤其是对“受过挫伤”但仍旧在运行的设施分外注意，随时留神其工作状态，发现问题及时处理。例如本案例中的存储设备，屡次异样断电后并没有马上呈现故障而是运行了一段时间后才忽然解体。3、做好数据备份，有了备份文件，就算是设施解体了也能够尽量减少损失，升高对失常业务的影响。

服务器数据恢复环境：某公司信息管理平台，若干台VMware虚拟机共享一台存储设备，供外部应用，该存储设备中寄存了公司大量重要数据。 服务器故障：该存储设备运行时，管理员在存储网络中连贯了一台Windows服务器，这台存储设备忽然无奈失常应用。管理员对该存储设备进行初步查看后发现该存储设备中的虚构磁盘失落，分区表失落，重启该存储设备后故障仍旧。因为该存储设备中的数据非常重要且没有备份，管理员不敢擅自进行操作。 服务器数据恢复过程：1、通过管理员的形容，数据恢复工程师初步判断该存储设备解体并非是硬件故障导致的。依照正规数据恢复流程和审慎思考，硬件工程师还是对故障存储设备中的所有硬盘进行了物理故障检测，检测后果和初步判断统一：所有硬盘都能够失常读取，没有发现任何物理故障。2、将故障存储中所有硬盘编号后取出，以只读形式将所有硬盘残缺镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。3、通过初步剖析，数据恢复工程师基本上能够确定该存储设备解体的起因就是管理员连贯的那台Windows服务器对故障存储的storage的独享操作毁坏了存储的VMFS卷。4、对存储的底层数据进行剖析后，数据恢复工程师发现：分区表被清零，然而分区表有55AA的无效完结标记，有硬盘ID标记。5、持续剖析发现存储中有一个没有任何数据的NTFS卷，持续剖析该卷的BITMAP后发现其大小与存储的全副空间大小相差无几，在卷的几个不同地位都有局部的占用，但所有占用的总空间很小。6、通过和管理员沟通和对底层数据的剖析，发现故障存储实际上有两个分区，第一个分区占总空间大小的80%，第二个分区是第一个分区的扩大分区，在ntfs分区对数据进行毁坏时并没有波及到第二个分区。所以数据恢复的要害在第一个分区，通过剖析与查问发现第一个分区的重要信息都还在。7、连贯故障存储的两个VMFS分区，依照分区的组织形式间接提取vmdk文件和配置文件。8、提取出文件后通过nfs回迁数据的形式进行数据恢复。复原实现后对后果进行校检，检测无误后交由用户方工程师来现场进行后果验证，验证没有问题后移交数据。 服务器数据恢复总结：这个数据失落的起因非常简略，就是因为光纤环境互斥不当导致了卷在Windows零碎下从新做了分区并且执行了NTFS格式化和删除分区的操作。因为esx vmfs的互斥是独立于硬件层面而只依赖于操作系统驱动层的，所以将存储接入其余服务器时肯定要留神存储的调配权限，防止造成数据失落。

服务器故障：北京某公司管理员误操作删除了XenServer虚拟化服务器上的一台虚拟机。服务器数据恢复工程师到现场对故障服务器进行初检后发现服务器内的VPS不可用，虚构磁盘数据失落。 服务器数据恢复过程：1、将故障服务器内的所有硬盘编号取出后以只读形式进行扇区级镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止故障服务器内的原始数据被再次毁坏。2、基于镜像文件对底层数据进行剖析。故障服务器内虚拟机磁盘采纳LVM的形式进行治理，虚拟机磁盘为精简模式。排查底层数据找到了局部尚未被更新的lvm信息。 3、剖析查找到的lvm信息并尝试还原虚构磁盘数据区，然而通过剖析后发现虚构磁盘数据区中的少数数据曾经被毁坏，只有sql sever数据库页碎片被保留下来了。4、基于对故障服务器底层数据的剖析后果，北亚企安数据恢复工程师团队决定应用碎片拼接的计划复原被毁坏的sql sever数据库。5、剖析sql sever数据库的起始地位，从头开始顺次扫描合乎sql sever数据库页的数据碎片，按程序将扫描到的sql sever数据库页碎片重组成一个残缺的mdf文件，校验文件的完整性，Mdf文件通过校验。 6、搭建一个sql sever数据库环境，将复原进去的mdf文件附加到刚搭建好的sql sever数据库环境中，查问相干表的最新数据状态，后果所有查问的数据失常，最近更新的数据残缺。 服务器数据验证：由用户方工程师对所有数据进行验证，通过重复验证确认复原数据残缺可用，本次服务器数据工作胜利。

服务器数据恢复环境：某公司一台web服务器，存储网站程序和网站内容数据，部署的MySQL数据库。6块硬盘组建的一组raid6磁盘阵列。 服务器故障：服务器raid6中有3块硬盘离线，服务器解体。服务器上部署的MySQL数据库数据失落，服务器上跑的网站关停，业务中断。Tips：Raid6是双校验，能够看作raid5的升级版，raid6在raid5奇偶校验的根底上又减少了一种校验。raid5是N-1的空间使用率，raid6是N-2的空间使用率。raid6磁盘阵列和raid5磁盘阵列的数据恢复流程基本相同。 服务器数据恢复过程：1、将故障服务器中所有硬盘依照程序编号后取出，将硬盘以只读形式残缺镜像到数据存储池内，而后将所有硬盘依照编号还原到原服务器中交还用户，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、raid6是双校验：第一个校验与raid5雷同——xor异或校验；第二个校验是通过reed-solomon算法生成的一种比较复杂的校验模式。北亚企安数据恢复工程师基于镜像文件进行检测时发现这三块离线硬盘中有两块离线较早，盘内的数据对于数据恢复没有什么用途，只能应用第二个校验对最初掉线的那块硬盘进行剖析和数据提取。3、北亚企安数据恢复工程师团队通过对raid6磁盘阵列的原始参数的剖析后，调整北亚企安自研的RAID数据恢复程序来适应该raid6磁盘阵列的理论状况并提取磁盘阵列的数据生成一个镜像文件。4、对这个复原进去的镜像文件进行自检，自检通过没有发现任何问题，分割用户方亲自进行数据恢复后果的验证。用户方工程师通过验证后确认复原的数据残缺可用，本次raid6磁盘阵列数据恢复工作实现。

服务器数据恢复环境：某品牌EVA系列某型号存储设备，采纳的ESXI虚拟化零碎，虚拟机存储的是mysql数据库。 服务器故障：因为异样断电导致存储设备中的一台虚拟机无奈启动，管理员发现虚拟机无奈启动后再次重启服务器，然而该虚拟机仍然无奈失常启动。因为该虚拟机中的数据涉密极为重要，而且只能到现场进行复原，于是用户方分割咱们数据恢复核心寻求帮忙。 服务器数据恢复过程：1、达到用户现场后，复原工程师首先对故障存储中所有磁盘数据以只读形式进行齐全备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始磁盘中的原始数据造成二次毁坏。2、北亚企安数据恢复工程师基于镜像文件进行了检测，发现该故障虚拟机有两个快照。将两个虚拟机快照进行合并，以磁盘格式将合并的虚拟机镜像文件关上并进行剖析。通过剖析发现文件系统的外部数据有大量失落，有局部数据被清零，有局部数据被替换，并且数据库的索引文件也被替换。3、通过检测剖析，数据恢复工程师发现故障虚拟机中的数据次要是数据库文件。只有提取出虚拟机内的数据库文件即可实现虚拟机的数据恢复。4、因为故障存储设备中mysql数据库应用的是MyISAM引擎。MyISAM引擎应用独立表空间来存储数据，即各个表的数据是分别独立存储的，因而数据库索引文件被毁坏但文件存在的状况下仍然能够通过底层数据恢复数据库文件。5、北亚企安数据恢复核心的数据库工程师通过对镜像文件的剖析及修复提取出了mysql数据库文件数据。6、重建虚拟机环境并对复原进去的数据进行验证，发现仍然有局部数据被毁坏。通过剖析后推断呈现这个问题的起因是零碎表空间存在异样，这部分数据无奈修复。7、分割到用户方工程师进行现场验证，验证后确认故障虚拟机中有大略3%的数据没有复原进去，不过数据库的重要数据曾经胜利复原，没有复原进去的3%数据为非重要数据，不影响业务。用户认可本次数据恢复后果，本次虚拟机数据恢复工作实现。

Oracle数据库故障：北京某国企服务器中部署的Oracle 11g R2数据库被误操作执行了truncate table CM_CHECK_ITEM_HIS，表数据失落，查问该表时报错，数据库备份不可用，表数据无奈查问。Truncate数据原理：表被Truncate后，ORACLE会在数据字典和Segment Header中更新表的DATA_OBJECT_ID，然而不会批改理论数据局部的块。因为数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不统一，所以ORACLE服务过程在读取全表数据时读取不到曾经被TRUNCATE然而理论未被笼罩的数据。 Oracle数据库复原过程：1、为了爱护用户的原始数据和更好演示truncate table的数据恢复过程，北亚企安数据恢复工程师结构了与用户雷同的故障环境。用Scott用户创立表emp1，间断复制emp表屡次，总记录数为：7340032条。truncate表emp1，没有做其余任何操作。查问该表，Oracle数据库中该表的记录为0条。 注： Os：win server；Oracle数据库版本：win_oracle_11.2.0.1_x64。 2、剖析system表空间文件，找到truncate表的原始数据所在位置。 3、解析truncate表所在的数据库数据文件，找到truncate的数据。4、将truncate的数据插入到数据库中。通过解析system01.dbf文件，找到truncate的数据所在的地位，找到被删除的数据。解析表所在的数据文件，将truncate的数据插入到数据库中。在数据库中，查找被truncate的表，发现数据回来了，备份数据。 5、Exp导出scott用户。

服务器数据恢复环境：某公司的一台NetApp某型号存储；几十块磁盘组建两组存储池，两组存储池互为镜像；存储池划分卷并映射到ESXI作为数据存储应用，卷内有数百台虚拟机。 服务器故障：管理员操作失误导致卷失落，卷内虚拟机无法访问。管理员对该NetApp存储进行查看后尝试复原数据然而没有胜利。 服务器数据恢复过程：1、为避免可能对原始磁盘内的原始数据造成二次毁坏，首先将故障NetApp存储中的所有磁盘以只读形式进行镜像备份。2、剖析故障NetApp存储中磁盘阵列的底层数据，依据底层数据元信息确定磁盘阵列中每块磁盘的盘序及性能（数据/校验），确定无离线盘，无需校验信息，剔除掉校验盘。3、NetApp存储应用的文件系统为WAFL，本案例中的NetApp存储的文件系统采纳了高版本模式。填写好配置文件，应用北亚自主研发的NetApp解析程序进行解析。4、提取完数据后，由北亚企安数据恢复工程师对提取数据进行文件自测验，测验文件数据过程中发现数据文件异样。进行二次剖析后发现局部数据块因为指针异样被填充。此类指针在以往的案例中从未遇见过，没有现成的数据恢复计划可解决这个问题，只能将该case移交给北亚企安非常规业务技术攻关小组进行技术攻关。5、非常规业务技术攻关小组剖析&测试后得出结论：此类指针为压缩占用标记，并给出理解压算法。6、北亚企安数据恢复工程师依据解压算法编写数据解压程序，对提取数据进行解压验证。在解压过程中对呈现的异常情况进行调整，不断完善解压算法，最终实现理解压程序的编写，通过验证确认程序残缺可用。7、应用解压程序解压后的虚拟机VMDK可失常解析，解析&导出文件。将提取的文件样本移交给用户测验，通过用户方工程师的重复测验后一切正常。8、北亚企安数据恢复工程师持续调整数据提取程序，并增加目录块解析模块以及解压模块，提取故障NetApp存储卷内所有文件，进行批量数据恢复操作。 数据验证：待所有数据提取实现后，将数据迁徙到用户存储中进行验证，通过数据恢复工程师和客户方工程师的重复验证，确认数据残缺可用，本次数据恢复工作实现。