数据恢复

服务器数据恢复环境：服务器+10个磁盘柜，每个磁盘柜24块磁盘；9个磁盘柜的磁盘用来存储数据，另外1个磁盘柜用来存储元数据；存储元数据的24块磁盘的组成构造：9组RAID1磁盘阵列+1组4盘位的RAID10磁盘阵列+4个全局热备盘；存储数据的9×24=216块磁盘的组成构造：36组6盘RAID5阵列；36组RAID5磁盘阵列分为2个存储系统。服务器数据恢复环境架构：注：Meta_LUN(元数据卷) Data_LUN（用户数据卷） 服务器故障：存储数据的其中一个存储系统中一组RAID5阵列因为2块磁盘先后故障离线，该RAID5阵列生效，导致整个存储系统解体，无奈应用。 服务器数据恢复过程：1、将故障RAID5阵列中的6块成员盘编号标记，从磁盘柜中取出并接入到北亚企安数据备份服务器上，以只读形式对所有硬盘进行全盘镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止服务器数据恢复过程中误操作对原始数据造成二次毁坏。备份过程： 在备份过程中发现故障RAID5阵列中的1块离线硬盘存在大量的坏道，无奈持续备份。由硬件工程师对该故障盘收盘&更换固件并进行修复，通过解决后硬盘能够持续备份，但坏道依然存在。局部镜像文件： 2、基于镜像文件对故障RAID5阵列进行剖析，获取RAID相干信息，利用这些信息虚构重组RAID5阵列，将RAID中的LUN复原成镜像文件。通过剖析发现后离线硬盘损坏较为重大，存在大量坏道。登录存储设备的治理界面，获取到StorNext文件系统中和卷相干的一些根本信息。 3、剖析StorNext文件系统中的Meta卷和Data卷，发现该StorNext文件系统蕴含2个Data卷，每一个残缺的Data卷都是由多组RAID中的LUN组成。通过剖析这些LUN北亚企安数据恢复工程师钻研出LUN之间组合的算法法则，虚构重组出残缺的Data卷。 4、剖析Meta卷中的节点信息，目录项信息以及Meta卷和Data之间的对应关系。针对一个Meta卷治理多个Data卷的状况，北亚企安数据恢复工程师钻研出Meta卷到Data卷的索引算法。文件节点： 目录块： 5、通过下面通过剖析钻研获取到的全副信息，北亚企安数据恢复工程师编写程序扫描Meta卷中的节点信息和目录项信息，解析目录项和节点并获取残缺的StorNext文件系统目录构造。解析每一个节点中的指针信息，并将这些信息记录在数据库中。文件信息： 6、北亚企安数据恢复工程师编写文件提取程序读取数据库，联合解析出的信息以及两个Data卷之间的聚合算法提取数据。 数据验证：随机抽样检测复原进去的数据，没有发现。将数据移交给用户亲自验证，通过验证用户确认复原数据残缺可用。尽管故障硬盘存在大量坏道，所幸外围数据没有毁坏，本次数据恢复工作实现。

服务器数据恢复环境：MD1200磁盘柜+RAID卡创立的RAID5磁盘阵列，调配了一个LUN，LUN被划分为sdc1和sdc2两个分区。通过LVM扩容的形式，将sdc1分区退出到了root_lv中。sdc2分区被格式化为XFS文件系统。 服务器故障：用户对服务器进行了重装系统的操作后，发现sdc磁盘分区扭转，sdc2分区失落，无法访问。 服务器数据恢复过程：1、以只读形式对故障服务器上所有硬盘做镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止误操作对原始数据造成二次毁坏。2、基于镜像文件剖析故障服务器中raid5的盘序、条带大小等RAID相干信息。利用获取到的RAID相干信息虚构重组raid。3、定位到xfs文件系统的分区起始地位，校验xfs文件系统的完整性及正确性。4、修复xfs文件系统的超级块构造。修复实现的超级块：5、修复xfs文件系统中失落的节点及目录项。修复实现的根节点：重做的目录项：6、修复实现后北亚企安数据恢复工程师编写程序解析xfs文件系统并提取其中的数据。对失落的sdc2分区的xfs文件系统进行检测后发现，xfs文件系统头部的超级块及局部节点、目录项失落。依据超级块备份及文件系统中的目录树结构，北亚企安数据恢复工程师对超级块进行了修复还原，修补和重构失落的节点、目录项后，xfs文件系统中的数据得以残缺复原。修复实现的目录构造： 服务器数据恢复论断：通过数据恢复工程师和用户亲自验证后，复原进去的sdc2分区数据残缺无效。之所以数据得以残缺复原，是因为数据失落之后用户未做任何写入的破坏性操作。

服务器数据恢复环境：某公司一台DELL服务器，作为WEB服务器应用，装置的Windows Server操作系统，配置了SQL Server数据库；采纳了Xen Server虚拟化零碎；底层是通过raid卡，用4块STAT硬盘搭建的RAID10。 服务器故障：服务器意外断电导致虚拟机磁盘失落，虚拟机不可用。须要复原SQL Server数据库。 服务器数据恢复过程：1、将故障服务器中所有硬盘以只读形式进行镜像备份，后续的数据恢复剖析和数据恢复操作都基于镜像文件进行，不会对原服务器做任何操作，保障原服务器初始状态，防止对原始数据造成可能的二次毁坏。2、基于镜像文件对底层数据进行剖析，发现故障服务器中失落的虚拟机磁盘都采纳了LVM的构造。进入到“/etc/lvm/backup/”目录下查问看是否有损坏的虚构磁盘信息，如果有就意味着LVM信息尚有保留；如果没有就意味着虚构磁盘信息曾经被更新，只能通过底层数据查找没有更新的lvm信息。本案例中北亚企安数据恢复工程师从底层数据中查问到了尚未更新的lvm信息，见下图： 3、找到lvm信息就意味着数据还在。基于lvm信息剖析&查找虚构磁盘的分区数据，然而数据恢复工程师通过剖析后居然发现虚构磁盘被毁坏了，这种景象十分少见。通过进一步查找和剖析后确认该区域的数据的确被毁坏了，只能找到一些数据库页碎片，能够通过数据库碎片拼接的伎俩来复原数据，即依据数据库构造，将底层找到的数据库的页碎片依照原先的程序拼接起来，而后对数据库进行修复和校检后即可复原数据库。4、试图通过数据库备份来复原数据库。因为之前数据库做过一次备份，数据库备份文件和网站代码被一起压缩到一个RAR压缩包文件中。失常状况下rar压缩包的第一个扇区记录的是文件名，所以能够依据文件名反向查找压缩包的数据起始地位，把相应的压缩包底层数据提取进去并重命名。然而在理论的复原过程中却呈现了意外，提取进去的压缩包解压时报错，报错信息见下图： 5、尝试应用rar修复工具（设置为“疏忽谬误”）持续解压数据，依然解压失败。惯例的数据恢复办法行不通。只能通过数据库碎片拼接来复原数据库数据。6、在数据库层面剖析数据库开始地位，剖析出数据库开始地位后依据每个数据库页的编号和文件号去底层扫描合乎这个数据库页的所有数据，最初由北亚企安数据恢复工程师将所有扫描进去的数据重组为一个mdf文件。通过校验程序检测合格后提取数据。重组后的mdf文件见下图：  数据验证：通过北亚企安数据恢复工程师团队的不懈努力，最终将服务器内的数据全副提取进去并通过初步验证。搭建了数据库环境，将复原进去的数据库数据附加下来进行查问，最新数据都查问失常。本次数据恢复实现。复原后果见下图：

服务器数据恢复环境：几年前从一台物理服务器上迁徙到ESXI上的虚拟机，在迁徙实现后做了一个快照。 服务器故障：某天工作人员误操作还原了几年前迁徙实现后所做的快照，将这台虚拟机的数据恢复到几年前刚迁徙实现时候的状态，近3年的更新的数据全副失落。 服务器数据恢复原理：还原快照操作与删除数据在实质上是一样的，虚拟机删除快照后会将底层存储空间相应的地位开释，而后从新应用该局部空间存储新的数据。北亚企安数据恢复工程师在这里强调一下：如果一台设施上的虚拟机不小心还原了快照，应该尽快将该设施上所有虚构机关机或迁徙到其余ESXI上。复原数据之前须要先理解vmfs文件系统的底层构造。vmfs文件系统是wmware虚拟化的专有文件系统。vmfs文件系统下默认将所有的硬盘划分为若干区域，这些区域的最小单位被称为block。每个block的大小为1MB，每1024个block组成一个MAP。这些信息记录在vmfs文件系统的某一片特定区域内。每个map外面的block在物理硬盘上的存储程序不间断，但每个map里的所有block肯定是属于同一个文件的，FileSize= N × MAP × 1024（Block）。 在vmfs文件系统中，如果某文件被删除，在底层数据层面只是删除了文件的索引项，数据内容及指向数据map并没有被删除。 服务器数据恢复计划：1、提取整个vmfs文件系统里所有的闲暇map。2、找到合乎快照文件头构造的map。3、依据vmfs文件构造持续提取残余的文件碎片。4、将所有数据提取实现后，联合原有的vmdk合并成一个新的vmdk。5、将新合成的vmdk文件挂载，解释外面的数据即可实现虚拟机的数据恢复。

服务器故障&检测：某公司一台IBM某型号服务器共16块硬盘，管理员某天巡检的时候发现该服务器的10号和13号硬盘灯显示黄色，服务器宕机，服务器上跑的业务终止。通过IBM storage manager查问服务器状态，逻辑卷状态报告“失败”；6号盘的物理硬盘状态报告“正告”，10号和13号盘报告“失败”。通过IBM storage manager将以后服务器的日志进行残缺备份，在备份的同时剖析日志内容，取得局部逻辑卷信息用于前期数据恢复应用。 服务器数据恢复过程：1、将故障服务器内所有硬盘编号并取出。对所有硬盘进行物理故障检测，16块盘均能失常辨认。检测16块盘的SMART状态，后果发现6号盘的SMART状态为“正告”，和IBM storage manager中的报告统一。2、将故障服务器中所有磁盘以只读形式进行扇区级别的镜像备份。在镜像过程中6号磁盘的镜像速度异样迟缓，联合6号盘SMART状态能够判断6号盘应该存在大量损坏的不稳固扇区，无奈通过惯例形式进行镜像。3、应用业余设施对6号盘进行镜像，在镜像过程中发现6号盘的坏道并不多，只是存在大量不稳固扇区。调整镜像策略，批改“遇到坏道跳过扇区数”、“响应等待时间”等参数后持续对6号盘镜像。4、所有磁盘镜像实现后查看日志，发现在IBM storage manager和硬盘SMART状态中均没有发现异常的1号盘也存在坏道，10号和13号盘也存在大量不法则的坏道散布。依据坏道列表定位到指标镜像文件，通过剖析发现ext3文件系统的一些要害源数据信息被毁坏。只能等所有硬盘镜像实现后，通过同一条带进行xor以及依据文件系统上下文关系手动修复被损坏的文件系统。5、尽管6号盘镜像实现，然而先前所做的镜像策略会主动跳过一些不稳固扇区，所以6号盘的镜像是不残缺的。从新调整拷贝策略持续镜像被跳过的扇区，实现6号盘所有扇区镜像。6、实现所有硬盘的镜像后，北亚企安数据恢复工程师对ext3文件系统进行逆向剖析，联合对日志文件的剖析，最终获取到16块盘的盘序，RAID块大小，RAID的校验走向和形式等RAID相干信息。7、利用获取到的RAID相干信息虚构重组RAID，重组实现后解析ext3文件系统，通过和用户沟通后提取出oracle的dmp文件并尝试进行复原。在应用dmp文件进行复原的过程中，oracle报告imp-0008谬误。北亚企安的oracle工程师剖析dmp文件的日志文件后发现提取出的dmp文件有问题。8、从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。通过数据恢复工程师团队的不懈努力，终于从新提取出dmp文件和dbf原始库文件。将提取进去的dmp文件移交给用户，导入数据进行测试没有发现问题。对复原进去的dbf原始库文件进行校验，所有文件均通过测试。本次数据恢复工作实现。

服务器数据恢复环境：某公司一台服务器，应用FreeNAS做iSCSI，借助另外两台服务器做虚拟化零碎。此虚拟化零碎装置有5台虚拟机，其中3台虚拟机比拟重要：一台虚拟机部署了ASP.net、PHP，装置了SqlServer和mysql数据库；另一台装置的FreeBSD零碎并部署了MySQL数据库；一台虚拟机存储的是代码和数据。FreeNAS层采纳的是UFS2文件系统；服务器建一个文件而后挂载到ESXi零碎。 服务器故障：服务器意外断电后重启，虚拟化零碎无奈连贯服务器，UFS2文件系统呈现问题，管理员试图修复文件系统，然而实现修复后ESXi零碎无奈辨认原有的数据和文件系统。 服务器数据恢复过程：1、剖析本案例的利用构架档次：FreeNAS(UFS2文件系统–> 一个大的稠密模式的文件) –> ESXi(VMFS文件系统层) -> 单台虚拟机的虚构磁盘 (windows-NTFS文件系统/FreeBSD-UFS2文件系统)。2、对FreeNAS做残缺镜像，基于镜像文件剖析整个存储，在存储中只发现一个文件名为iscsidatade的大文件。3、依据UFS2文件系统的二进制构造定位到iscsidata文件的Inode数据，发现iscsidata文件被重建过，inode指针指向的数据量很少。Tips：如果FreeNAS层问题无奈解决，就无奈进入到下一步的VMFS层剖析。UFS2文件系统相干信息：块大小：16KBSegment大小：2KB柱面组大小：188176 KBUFS2文件系统的一个数据指针占用8字节，一个块可存储2048个数据指针，一个二级指针块则可存储2048×2048×16KB= 64GB的数据。一个三级指针块则可存储64GB×2048=128TB的数据。如果能找到iscsidata文件的三级指针块就能解决FreeNAS层问题。但iscsidata文件被重建过，预计有局部指针块已被笼罩。原iscsidata文件的inode和新建的iscsidata文件的inode就在同一个地位，尝试搜寻没有发现其它有用的inode。北亚企安数据恢复工程师只能编写程序来收集有用的指针块： 4、因为该iscsidata文件采纳的是稠密模式，放宽收集条件后收集到了大量的三级指针块和二级指针块。通过剖析后发现这些收集到的三级指针块都是有效的，没有发现iscsidata文件应用的三级指针块，预计在新建iscsidata文件时被笼罩（新的iscsidata文件挂载到ESXi后有个VMFS格式化过程，而 该ESXi版本应用的是GPT分区，GPT分区会在磁盘最初写入冗余的GPT头和分区表信息数据，会应用iscsidata文件的三级指针块）。5、剖析收集到的二级指针块，对有大量二级指针块的指向数据进行DUMP，再从磁盘中的数据定位到二级指针，通过这种形式失去大量DUMP的数据。6、VMFS被从新格式化过，原UFS2文件系统的指针已失落，所以VMFS元文件不可用。只能通过单台虚拟机层(windows(NTFS)和FreeBSD(UFS2)零碎的文件系统构造)向上定位到VMFS层，再通过VMFS层定位到DUMP出的单个64GB文件。通过屡次组合，最终将三台重要虚拟机的虚构磁盘完全恢复。将复原出的网页数据和数据库数据上传到筹备好的环境中，起利用后没有发现问题。

服务器数据恢复环境：某品牌ProLiant DL系列服务器，6块SAS硬盘组成RAID5磁盘阵列，WINDOWS SERVER操作系统，存储了企业的外部文件。 服务器故障&剖析：服务器在产生故障前有过几次意外断电，每次断电重启后没有出现异常。直到最初一次断电重启没有胜利，RAID报错，提醒无奈找到存储设备。进入RAID治理模块，执行任何操作就死机。管理员屡次重启服务器后还是无奈胜利进入操作系统。通常服务器呈现这类故障，有很大的可能性是因为意外断电导致RAID模块损坏（RAID治理信息失落或RAID模块硬件损坏）。RAID阵列创立实现后，治理模块信息就会固定下来不会再发生变化。然而raid阵列的模块信息毕竟不是只读的，也是能够批改的，而意外断电就可能导致模块信息被篡改或者失落，屡次断电甚至可能导致RAID卡元器件损坏，服务器失去对多块物理硬盘进行RAID治理的中间层模块。依据本案例服务器的故障体现，北亚企安数据恢复工程师初步判断故障起因就是RAID卡硬件损坏，如果是这种状况，通过惯例办法无奈获取6块磁盘中的数据。 服务器数据恢复过程：1、通过物理故障检测发现故障服务器内的所有硬盘均能够失常读取，无物理故障。2、编号后将故障服务器内的所有硬盘以只读形式进行镜像备份，镜像实现后将所有硬盘依照编号还原到故障服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。3、基于镜像文件，北亚企安数据恢复工程师剖析故障服务器中raid5磁盘阵列构造，确定raid阵列的硬盘程序、数据块大小、阵列校验形式等raid相干信息。4、利用获取到的raid阵列信息虚构重构raid阵列并进行逻辑校验，确保重构RAID各项参数正确无误后验证重要数据。5、通过数据恢复工程师验证后没有发现异常，让管理员亲自验证无问题后将数据迁徙到提前准备好的环境中，本次数据恢复工作实现。 服务器数据安全Tips：1、尽量保障机房供电稳固，重要设施装备UPS，以缩小供电异样影响服务器及存储的失常工作。2、应定期对老旧设施进行安全检查，评估老旧设施的运行状态，评估是否须要对老旧设施进行硬件降级或者系统升级。3、提前制订突发事件应急解决计划，以升高异样断电带来的损失。

服务器数据恢复环境（EVA系列存储）介绍：EVA系列存储是一套"虚构"磁盘阵列存储解决方案，其构造不同于基于RAID的一般存储，在HP公司外部被称为VRAID。EVA对每个物理磁盘(PV)进行签名(写在每个磁盘的0扇区)，签名后每个物理磁盘(PV)会被调配进不同的DISK GROUP。在DISK GROUP中，每个PV会按肯定大小划分为若干存储单元(PP)，PP的大小为2的整数次幂，在2-16M之间。每个PV中有肯定数量的PP，这些PP独特构建了DISK GROUP的可用空间。PV依照5-15组成若干组RSS(惯例RAID的冗余组)，但这个冗余组不等同于惯例RAID，惯例RAID是以磁盘为单位的RAID算法，而RSS是基于PP的RAID算法。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组中其余磁盘(同一条带中已存在的PV之外)中寻找可用的PP，在逻辑上实现每个stripe的rebuild，从而保障整个存储的安全性。当一个RSS中损坏的磁盘数量少于或者等于6个，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、解释镜像文件或指标磁盘，迁徙镜像或导出外部文件。

数据库故障：Oracle数据库的ASM磁盘组掉线，ASM实例不能挂载。管理员尝试修复数据库然而没有胜利。 数据库数据恢复计划：数据库数据恢复工程师通过剖析组成ASM磁盘组的磁盘底层数据，将ASM元数据提取进去做进一步剖析，发现ASM存储元数据曾经损坏，导致diskgroup无奈挂载。数据库数据恢复工程师将ASM存储空间重组，而后导出ASM磁盘组外面的数据库文件，检测导出的数据库文件并进行复原。如果通过检测确认数据库文件是残缺的，就能够间接应用数据库文件启动数据库；如果数据库文件损坏，就须要解析底层的数据库文件并复原。 数据库数据恢复过程：1、将故障服务器中的所有硬盘以只读形式镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、依照下面的数据库数据恢复计划剖析底层数据并进行提取，获取到ASM元数据，应用ASM元数据重组ASM存储空间。3、ASM存储空间重组实现后，应用到北亚企安自研的ASM解析工具解析ASM构造，提取ASM中的oracle数据库文件。4、检测提取出的oracle数据库文件。检测后果：5、应用北亚企安自研的oracle数据库解析工具解析所有数据库文件中的数据记录，而后依照用户导入到新的oracle数据库中。6、数据库数据恢复工程师通过抽查数据表的形式对复原进去的数据库进行验证，没有发现异常。让用户亲自验证数据，通过重复验证后，确认数据残缺可用，本次Oracle数据库数据恢复工作实现。

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

VSAN简介：VSAN是以vSphere内核为根底开发，能够扩大应用的分布式存储架构。该架构在vSphere集群主机中安硬盘及闪存构建VSAN存储层，通过存储进行治理与管制，最终造成一个共享存储层。VSAN数据存储是一个对象存储，以文件系统的模式出现给vSphere主机。这个对象存储服务会从VSAN集群中的每台主机上加载卷，而后展示为繁多的、在所有节点上可见的分布式共享数据存储。VSAN简化了存储配置，对于虚拟机来说就只有一个数据存储。这个分布式数据存储来自VSAN集群中每台vSphere主机上的存储空间，通过磁盘组进行配置，在独自的存储实体中存储所有的虚拟机文件。如果闪存盘或者容量盘呈现故障的时候，数据会向其余节点转移，尽管这种存储形式绝对平安，然而在转移的过程中也有可能呈现其余故障。 服务器数据恢复环境：四台服务器节点组成的VSAN集群；每台服务器节点上有两个磁盘组；每个磁盘组由一块SSD硬盘+5块SAS硬盘组成，SSD做闪存，SAS做容量盘。 服务器故障：其中一个服务器节点上的一个磁盘组中的容量盘呈现故障离线，这个时候VSAN开始数据重构&迁徙，在迁徙还没有实现的时候机房停电。复电重启设施后发现该服务器节点上另外一个磁盘组中有两块容量盘故障离线，数据存储呈现故障。尽管能够登陆VSAN治理控制台，然而所有的虚拟机都无法访问了。 服务器数据恢复过程：1、把四个服务器节点的所有硬盘以只读形式做镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件剖析底层数据的存储构造，确认虚拟机所在硬盘的散布信息。北亚企安数据恢复工程师依据剖析进去的数据存储构造开发相应的程序来测试数据散布信息的准确性。3、独自剖析每个服务器节点上的两个磁盘组，搞清楚磁盘组内的闪存盘和容量盘之间的对应关系，每块硬盘都有一个惟一标识进行磁盘间的对应。a、获取每块磁盘的UUID和磁盘组的UUIDb、获取每个磁盘组中的容量盘的组件信息。c、依据容量盘的组件信息中记录的组件的MAP地位提取组件位图。d、依据组件位图提取组件数据和缓存数据。e、依据组件的形容信息获取组件所属对象和组件程序，把组件合并成对象。f、依据对象提取数据。能够将对象看成一个卷，也能够把对象看做一个逻辑卷，每个数据存储上的VSAN对象都是由多个组件形成，这些组件散布于集群主机上配置的磁盘组中。在复原VSAN数据过程中，组件信息的提取是要害。本案例故障组件损坏比拟少，复原进去的虚拟机都能失常启动。

服务器数据恢复环境：一台Web服务器中有一组由8块磁盘组建的raid6磁盘阵列，用来运行数据库和存储一般办公文件。 服务器故障：服务器raid6磁盘阵列中有两块硬盘离线，然而管理员没有留神到这种状况，没有及时更换离线硬盘。不久之后该raid6磁盘阵列中又有一块硬盘离线，超出了raid6冗余级别所容许的最大数量，就是这块硬盘的离线导致该raid6阵列的解体。通过沟通后理解到：该服务器呈现故障后，用户方曾经找过一家数据恢复服务商对故障服务器做了数据恢复并复原了大部分的数据，然而还是有局部数据受到严重破坏无奈应用，近几十天更新的办公文件也没有复原进去。 服务器数据恢复过程：1、咱们数据恢复核心拿到故障服务器所有硬盘之后，将所有硬盘连贯到北亚企安数据恢复服务器上以只读形式做镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据再次造成毁坏。2、剖析镜像文件发现该raid6磁盘阵列内最先离线的两块硬盘至多有数月没有写入过新的数据了，所以是否胜利复原故障服务器数据的要害就在于最初离线那块硬盘。3、故障服务器raid6磁盘阵列应用的是双校验，然而因为最早离线的两块磁盘曾经处于离线状态很长时间了，通过一般的异或运算曾经无奈复原该raid6阵列中的失落数据了。4、北亚企安数据恢复工程师决定应用基于Reed-Solomon算法生成的第二种校验形式来复原数据，这种数据恢复办法是北亚企安数据恢复核心的外围算法之一。5、依据该外围算法，北亚企安数据恢复工程师编写小程序重组和提取被毁坏的数据，生成残缺镜像。6、对提取进去的数据进行验证没有发现问题后分割用户方亲自验证数据。通过用户重复验证，确认故障服务器内所有数据残缺可用，数据库也可失常应用，本次数据恢复工作实现。

服务器数据恢复环境：某品牌V7000存储，由存储机柜加一组存储机头组成，共72块硬盘搭建了6组Mdisk组成存储池。其中包含3块热备盘，发现故障时候一块热备盘曾经启用。 服务器故障：存储中一块硬盘离线后热备盘主动启用并开始同步数据，在数据同步过程中与最早离线硬盘同一组的mdisk中又有一块硬盘离线，导致这组mdisk生效，热备盘同步失败，整个存储设备瘫痪。 服务器数据恢复过程：1、对故障存储所有硬盘以只读形式进行镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、服务器数据恢复工程师依据用户提供的一部分阵列配置信息把故障存储设备内的所有硬盘依照mdisk进行分类，3、依照mdisk程序剖析每组mdisk中硬盘的底层数据，获取故障存储中raid阵列的相干信息。4、基于获取到的所有相干信息，应用北亚企安自主研发的工具虚构重组mdisk。5、实现mdisk重组后，持续剖析mdisk，获取到故障存储中整个存储池的相干信息。6、基于存储池相干信息，应用北亚企安自主开发工具虚构重组整个存储池。 服务器数据验证：抽样验证重组进去的存储池数据，没有发现异常后分割用户方亲自验证。通过用户方重复验证，确认复原进去的数据残缺可用。将所有复原进去的数据迁徙到用户方从新搭建的环境中，再次验证没有问题。本次数据工作实现。

服务器数据恢复环境：某品牌PowerEdge系列服务器，磁盘阵列存储型号为该品牌MD3200系列存储，调配lun；linux centos 7操作系统，EXT4文件系统。 服务器故障：服务器在工作中因为未知起因忽然关机且无奈启动，管理员通过修复后能够启动服务器，但服务器的某个分区无奈挂载。管理员对无奈挂载的分区执行了fsck修复，修复实现后该分区能够胜利挂载，然而查看该分区数据后发现局部文件失落。 服务器数据恢复过程：1、数据恢复工程师达到现场后将故障服务器以只读模式映射到北亚企安数据恢复服务器上，将所有硬盘数据以只读形式镜像到数据恢复服务器上，后续数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、通过对镜像文件的剖析，数据恢复工程师初步诊断导致该服务器故障的起因是机房供电不稳引起的服务器非正常关机。3、仔细分析故障服务器的底层数据，发现服务器的异样断电导致目录项被毁坏，所幸的是底层数据仍然存在，只须要数据恢复工程师手工修复即可复原数据。4、因为管理员对文件系统执行了fsck修复，被毁坏的目录项在修复失败后以目录节点号命名，并寄存于lost+found目录内，随后又革除了这些目录项所对应的数据区索引。这就是分区挂载胜利后局部文件失落的起因。这样的状况想要复原数据，能够依据被删除的虚构磁盘文件的文件系统和文件类型在vmfs卷自由空间中进行排查，匹配碎片并从新合并，最终通过这种形式将删除的虚构磁盘文件复原。5、因为故障服务器采纳的是EXT4文件系统，EXT4文件系统有一个特点就是文件失落后其节点信息也会被革除，所以在本案例不能采纳基于节点信息进行还原的办法来复原数据，而是依据失落的文件目录项节点号匹配lost+found目录下的文件名称这种形式来复原数据。因为lost+found目录下的文件命名规定就是该文件的目录项节点号。能够先提取目录项节点号并与lost+found目录下的文件名进行一一对应，最终还原出服务器的原始目录构造。6、基于镜像文件剖析底层，在底层空间扫描目录项的区域，将目录项的节点号、数量等信息进行统计和记录，依据服务器磁盘中的文件系统信息将统计到的目录项和节点号进行整合匹配，而后匹配lost+found目录下的文件记录号，最终将服务器分区失落的数据恢复进去。7、通过管理员对复原进去的数据进行重复验证后，确认复原进去的数据残缺无效，本次数据恢复工作实现。

服务器数据恢复环境：华为s系列服务器；24块硬盘组成一组raid5磁盘阵列，其中蕴含1块热备盘。 服务器故障&检测：服务器工作状态下raid5中有一块硬盘离线，热备盘激活替换离线硬盘并开始进行数据同步，在同步的过程中该raid5阵列内的另一块硬盘因为未知起因离线，下层利用解体，服务器内的数据失落。拿到故障服务器内的所有硬盘后，硬件工程师对所有硬盘进行物理故障检测，发现除了其中的一块硬盘外，其余硬盘均能够失常读取无物理故障。 服务器数据恢复过程：1、将故障服务器内所有硬盘以只读形式做残缺的镜像备份，后续数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、因为华为s系列服务器的控制器的磁盘检测策略十分严格。对于没有物理故障但性能不稳固的硬盘，控制器会将其视作坏盘踢出阵列。之前检测到只有一块硬盘存在物理故障，因而故障服务器中掉线的两块盘中另外一块是因为读写不稳固被视作坏盘踢出而掉线。3、对每一块硬盘底层进行剖析，获取到raid阵列的条带大小、数据走向、硬盘程序、热备盘、数据库的散布法则等raid相干信息。依据剖析获取到的raid阵列信息重组raid。4、依据剖析获取到的阵列相干信息，应用北亚企安自主研发的工具重组原始raid5阵列。5、在重组过程中发现有一块硬盘内的数据在同步时候被毁坏。因为在数据恢复过程中须要将数据被损坏的硬盘排除，于是数据恢复工程师对所有硬盘进行了底层数据结构的比照。比照发现其中一块硬盘在雷同条带上的数据与其余硬盘显著不同。6、应用北亚自主研发的raid校验程序对该硬盘进行条带校验，确认该硬盘数据曾经在同步的时候被毁坏。排除这块硬盘后重组raid5磁盘阵列。7、实现raid阵列重组后，剖析lun在raid中的分配情况及数据块map。只有能将map残缺提取进去，就能够进行解析并提取lun数据。8、北亚企安数据恢复工程师编写文件系统解析程序对阵列内文件系统进行解析并导出数据库文件。9、由数据库工程师对提取的数据库文件进行校验和修复。数据库工程师对数据库文件进行验证后发现局部数据库文件及日志文件异样，表空间内存在大量坏块、所有管制文件被毁坏，undotbs02失落，数据库工程师对数据库文件进行了修复。修复过程： 数据验证：通过数据库工程师对数据库文件的修复和验证，最终复原出所有的数据库文件。服务器数据恢复工程师将修复胜利的数据库数据导入到筹备好的环境中进行验证，所有数据失常。分割用户亲自对数据进行验证均无异样。本次数据恢复工作实现。

服务器数据恢复环境：某公司一台服务器组建了一组raid5磁盘阵列，作为共享存储池应用。该服务器存储数据库文件和一般文件。 服务器故障&检测：RAID5磁盘阵列的硬盘掉线导致服务器操作系统辨认不到D分区。管理员重启了服务器，服务器raid5磁盘阵列的掉线硬盘从新上线并开始同步数据，数据同步到靠近40%的时候管理员感觉这样操作有问题，于是强制关机并分割咱们数据恢复核心寻求帮忙。北亚企安数据恢复工程师达到现场后，首先由硬件工程师对故障服务器的硬盘进行物理故障检测，经检测所有硬盘都不存在物理故障，能够失常读取。初步推断raid5磁盘阵列中的硬盘离线起因是读写不稳固。 服务器数据恢复过程：1、对故障服务器中所有硬盘以只读形式进行扇区级别的镜像备份，后续的数据分析和数据恢复操作都在镜像文件上进行，防止对原始数据造成二次毁坏。2、剖析镜像数据，获取故障服务器原始raid5磁盘阵列的相干信息如：raid阵列条带大小、盘序等。通过和管理员沟通弄清楚故障服务器原始raid5磁盘阵列的配置信息，而后将故障服务器内所有硬盘依照mdisk组进行分类。3、通过剖析mdisk组，北亚企安数据恢复工程师获取到故障服务器中所有硬盘的阵列组信息，利用获取到的上述信息重组raid阵列并提取阵列数据。4、对提取进去的数据进行校验，发现数据不残缺，局部数据库文件被毁坏。数据恢复工程师从新扫描故障服务器内的数据碎片并提取。5、数据库数据恢复工程师对提取进去的碎片进行剖析并重组拼接，验证dat数据完整性发现底层构造显示有损坏。6、持续扫描分区自由空间，拼合自在空间数据碎片并从新生成数据库文件。验证数据库文件，数据库能够失常加载，下层利用失常应用。7、数据恢复工程师验证实现后把数据交付给用户方亲自验证，经用户方工程师重复验证，确认复原进去的数据残缺可用，本次服务器数据恢复工作实现。

服务器数据恢复环境：SUN ZFS系列某型号存储阵列；40块磁盘组建的存储池（其中4块磁盘用作全局热备盘），池内划分出若干空间映射到服务器应用；服务器应用Windows操作系统。 服务器故障：服务器在工作时因为未知起因解体，排除断电、进水或者误操作等内部因素。管理员重启服务器后发现无奈进入零碎，须要复原该存储内的所有数据。 服务器数据恢复过程：1、对故障存储中所有硬盘以只读形式做镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、剖析磁盘镜像，发现故障设施是通过ZFS文件系统来治理所有磁盘。磁盘内记录零碎元信息的NVLIST较为凌乱，只能粗略得悉以下信息：故障存储中的磁盘被分为三组，每组12块；每个组应用ZFS文件系统独有的RAIDZ治理磁盘。RAIDZ级别为2，即每个组最多可缺失2块磁盘；故障存储内的4块全局热备全副启用。Tips：ZFS文件系统中的池被称为ZPOOL。ZPOOL的子设施能够有很多类型：块设施、文件、磁盘等等。本案例中所采纳三组RAIDZ作为子设施。3、通过进一步剖析，发现三组RAIDZ内有两组别离启用的热备盘个数为1和3。在热备盘启用后，第一组内又呈现一块离线盘，第二组内则又呈现两块离线盘。通过下面剖析失去的论断能够模仿故障现场：三组RAIDZ中的第一组和第二组别离呈现离线盘，热备盘及时进行替换；在热备盘无冗余的状态下第一组RAIDZ又呈现一块离线盘，第二组RAIDZ则又呈现两块离线盘，ZPOOL进入高负荷状态（每次读取数据都须要通过校验能力失去正确数据）。当第二组RAIDZ呈现了第三块离线盘时候，RAIDZ解体、ZPOOL下线、服务器解体。4、因为ZFS文件系统治理的存储池与惯例存储不同。惯例RAID在存储数据时只会依照特定的规定组建池，不关怀文件在子设施上的地位。而ZFS文件系统在存储数据时会为每次写入的数据调配适当大小的空间，并计算出指向子设施的数据指针。ZFS文件系统的这种个性决定了RAIDZ缺盘时无奈间接通过校验失去数据，必须将整个ZPOOL作为一个整体进行解析。于是，北亚企安数据恢复工程师手工截取事务块数据，并编写程序获取最大事务号入口。获取文件系统入口： 获取到文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序进行地址解析。解析数据指针： 获取到文件系统入口点在各磁盘的散布状况后，数据恢复工程师开始手工截取并剖析文件系统内部结构。因为入口散布所在的磁盘组无缺失盘，可间接提取信息。依据ZFS文件系统的数据存储构造找到用户映射的LUN名称，进而找到其节点。5、通过剖析发现故障存储中的ZFS文件系统版本与开源版本有很大差异，无奈应用之前开发的解析程序进行解析，所以北亚企安数据恢复工程师从新编写了数据提取程序提取数据。 6、因为磁盘组内缺盘个数较多，每个IO流都须要通过校验失去，所以提取进度极为迟缓。与用户沟通后得悉，此ZVOL卷映射到XenServer作为存储设备，用户所需的文件在其中一个大小约为2T的vhd内。提取ZVOL卷头部信息，依照XenStore卷存储构造进行剖析，发现这个2T的vhd在整个卷的尾部，计算其起始地位后从此地位开始提取数据。7、Vhd提取结束后，验证其外部的压缩包、图片和视频等文件，均可失常关上。分割用户亲自验证数据，通过重复验证后确定文件数量与零碎自动记录的文件数量相差无几，缺失的那局部极少数量的文件可能因为是最新生成还未刷新到磁盘。验证文件可用性，文件全副可失常关上，本次数据恢复工作实现。

服务器数据恢复环境&故障：一台某品牌的存储设备，Windows操作系统。因为业务需要，须要把这台存储设备中的数据迁徙到另外一台存储设备中，在迁徙数据过程中忽然无奈读取数据，治理界面报错。管理员查看服务器内的数据发现其中一个lun的数据失落，须要进行针对性的数据恢复操作。 服务器数据恢复过程：1、首先检测故障存储内的所有硬盘，没有发现物理故障。对存储中所有硬盘以只读形式进行镜像备份，后续数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件对底层数据进行剖析，发现原存储设备被划分为多个组，每组最多能够缺失2块硬盘，所有硬盘均由ZFS文件系统治理。3、ZFS文件系统会在状态更新时更新文件系统入口，通过剖析获取到最新的入口指针，北亚企安数据恢复工程师编写解析程序对文件系统入口程序进行地址解析，最终获取到故障存储内所有硬盘的文件系统入口点，顺藤摸瓜找到lun节点。4、依据故障存储设备理论状况，北亚企安数据恢复工程师编写数据重组恢复程序提取存储数据。5、提取实现后由管理员对复原出的数据进行验证，所有文件均能够失常关上和编辑，认可本次数据恢复后果。6、在管理员的配合下，数据恢复工程师将复原进去的数据迁徙到用户筹备好的存储中，验证没有问题。本次数据恢复工作实现。 服务器数据恢复Tip：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器磁盘阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。4、当服务器因为未知起因的故障而导致系统解体或者文件不辨认/不可用时，通常不倡议自觉地在服务器上进行数据分析和数据恢复操作。如果的确对本人的数据恢复技术有自信，必须先对原服务器的所有硬盘数据进行镜像备份，数据分析和数据恢复操作只能在镜像文件上进行，防止操作失误毁坏原始数据，让后续的数据恢复难度减少。

服务器数据恢复环境：VMWARE VSAN蕴含三台服务器节点；每个服务器节点上配置2块SSD硬盘和4块机械硬盘；每个服务器节点上创立两个磁盘组；每个磁盘组采纳1个SSD硬盘作为缓存盘，2个机械硬盘作为容量盘，三个服务器节点共6个磁盘组组成VSAN存储空间来寄存虚拟机文件。 服务器故障：非正常关机导致VSAN逻辑架构呈现故障，局部虚拟机磁盘组件呈现问题，磁盘文件失落。 服务器数据恢复过程：1、为防止数据恢复过程中对原始数据造成二次毁坏， 在数据恢复之前对所有硬盘以只读形式做镜像备份，后续的数据恢复操作都基于镜像文件进行。扫描镜像文件后发现故障虚拟机的元数据和组件信息没有蒙受严重破坏，保留较为残缺。2、VSAN中的所有文件是以对象的形式存在，每个对象被宰割为多个组件。扫描所有组件信息，组件信息中记录着组件ID和该组件属于哪个对象的对象ID等信息。北亚企安数据恢复工程师编写程序扫描组件信息。3、依据扫描进去的组件信息找到每个数据块和该块在组件的逻辑地位，而后由北亚企安数据恢复工程师编写程序提取残缺组件。4、依据组件信息中的形容信息，将组件依照形容信息中记录的RAID级别和各个组件在对象中的逻辑地位进行组合，拼接出残缺的对象，即残缺的vmdk文件。5、因为每个组件可能会有局部数据留存在缓存盘上，而并没有写入到容量盘中，北亚企安数据恢复工程师编写程序将缓存盘上的数据刷新到对应的组件或对象中。6、对于有快照的vmdk文件，将快照和父盘进行合并。7、解析合并实现后的vmdk文件并提取其中的SQL server数据库备份文件。8、装置SQL server数据库，将提取进去的数据库备份文件进行还原操作，还原过程中和还原之后没有呈现任何报错。还原实现后检测数据库的完整性，也无任何报错。9、由用户亲自检测所有复原进去的数据，确认复原进去的数据残缺可用，本次vsan数据恢复工作实现。

服务器数据恢复环境：NetApp某型号存储；装备SAS硬盘，该硬盘520字节一个扇区；所有的lun映射到小型机应用，寄存Oracle数据库文件，采纳ASM裸设施存储形式。 服务器故障：管理员误操作删除NetApp存储上的所有lun。和管理员沟通后得悉：因为业务变动，须要从新布局存储空间，管理员间接把存储卷全副删除并重新分配。在执行删除操作之后还没有来得及调配的时候，下层业务忽然宕机了。运维工程师紧急排查故障状况，发现业务服务器上的磁盘都不见了，无法访问数据。 服务器数据恢复过程：1、为了防止在数据恢复过程中对原始数据造成二次毁坏，把故障存储中的每块磁盘以只读形式做齐全镜像，后续的所有数据恢复操作都在镜像文件上进行。2、剖析Netapp存储的存储过程。a、剖析盘序和LVM的组成形式。b、扫描硬盘内的所有节点。c、在节点扫描后果中找到文件大小合乎需要的节点并提取此节点。d、依据索引根内的第一级数据指针提取本文件的所有间接数据指针，在指针提取结束后开始提取文件数据。3、在硬盘后面的扇区地位查找超级块的相干信息。netapp超级块信息： 数据块有数据块形容信息，依据这些信息能够判断出哪些磁盘是校验盘（提取数据时需剔除）。校验块形容信息： 4、依据每块磁盘的磁盘信息以及磁盘的RAID盘序表确定盘序。首先要确定各个磁盘所属aggr组，而后再判断组内盘序。netapp盘序表： 5、Netapp的节点散布在数量泛滥的数据块内，在数据块内节点又被对立组织为节点组。每个节点组的局部字节记录一些零碎数据，局部字节为一项来记录各个文件节点。依据用户级别文件节点可分为两类：系统文件节点和用户文件节点。 netapp节点： 6、获取目录项，依据其节点编号找到对应节点。目录项信息： 7、剖析好存储构造之后，应用北亚企安自研的NetApp解析程序提取数据，解析asm文件系统并提取出数据库文件。 8、搭建小机环境，装置oracle数据库，验证数据库文件和备份文件。a、检测数据库文件。应用提取出的数据库文件启动数据库，能够失常启动。b、检测数据库备份文件。筛选出最新的数据库备份文件，应用筛选出的备份文件还原数据库，通过逐个尝试，没有发现问题。用户亲自验证后确认数据库复原确认无误，本次数据恢复工作实现。

服务器数据恢复环境：WinServer操作系统服务器，部署Hyper-V虚拟机环境；虚拟机的硬盘文件和配置文件存储在一台存储设备中；该存储设备配置：一组4盘raid5阵列寄存虚拟机数据+单块盘寄存虚拟机数据备份。 服务器故障：因为MD3200存储中虚拟机的数据文件失落，导致整个Hyper-V服务瘫痪，虚拟机无奈应用。 服务器故障检测：1、检测物理故障，后果没有发现物理故障问题，所有硬盘均失常。2、检测操作系统：操作系统失常运行，未发现错误过程。3、检测失落数据硬盘的文件系统：关上失常，检测无病毒，排除病毒破坏。持续剖析失落数据硬盘的文件系统，发现文件系统的元文件创建工夫（即文件系统的创立工夫）与数据失落的工夫雷同。这种状况意味着文件系统被人为重写，即分区被格式化了。4、查看系统日志：系统日志数据失落之前及当天的系统日志已被清空，然而审核日志和服务日志还在，凑巧格式化分区的操作只记录在系统日志中。这种状况再次印证这次数据劫难是人为导致的。5、尝试复原系统日志，从底层数据查看发现须要复原的系统日志已被新的日志记录笼罩，无奈复原。6、剖析所有分区，发现只有两个分区的文件系统被从新写入新的文件系统。因为两个分区的格式化须要有两个独立的过程，这种针对性的操作再次证实本次数据劫难由人为操作导致。 服务器数据恢复过程：1、将故障存储设备中所有的硬盘编号取出，以只读形式对所有硬盘做全盘镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。备份所有硬盘数据： 2、镜像实现后，基于镜像文件剖析RAID5磁盘阵列相干信息如条带大小、条带走向等。依据这些信息重组raid5磁盘阵列。 重组RAID5磁盘阵列： 关上RAID5磁盘阵列： 3、剖析硬盘底层数据发现还残留着许多以前文件系统的目录项及文件索引。通过核查发现这些文件索引指向的数据都是用户失落的文件内容。北亚企安数据恢复工程师编写提取文件索引项的小程序扫描并提取所有文件的文件索引项。 4、剖析提取进去的文件索引项，发现这些索引项都是不间断的，大多数都是以16K或8K对齐的。失常状况下文件索引项是间断的，大小为固定的1K，每个文件索引项对应一个文件或目录。而扫描进去的这些不间断并且不残缺的文件索引项是无奈失常索引到文件内容的，因而须要解决这些扫描进去的文件索引项。在扫描进去的文件索引项中搜寻” .VHD”，能找到一个” .VHD”的文件记录，而后将这个片间断的文件索引项提取进去。接着再查看这段提取进去的文件索引项中是否有指向下一段文件索引项的记录或者H20属性。如果有则依据文件索引项中的特色去匹配下一段文件索引项，如果没有则跳过这段文件索引项。依据以上办法能找到了大多数的文件索引项片段，而缺失的文件索引项片段有可能被毁坏了，能够从数据备份盘中去查找缺失的文件索引项片段，最终能够找到大部分的文件索引项。 文件索引项截图： 5、找到所有能找到的文件索引项之后，依据文件索引项的编号将其拼接成整个目录项构造。以下是搜寻到的局部文件索引项，尽管小局部文件索引项被毁坏，但这些找到的文件索引项曾经足够拼接整个目录构造。 扫描到的文件索引项碎片： 6、将重建好的目录构造替换现有文件系统中的目录构造并批改局部校验值，而后解释这个目录构造就能够看到失落的数据了。 解释进去的目录构造： 为了验证数据是否正确，将其中一个最新的VHD文件拷贝到一台反对附加VHD的服务器上，尝试附加此VHD，后果附加胜利。查看VHD中最新的数据的残缺度，没有发现问题后将所有数据恢复到一块硬盘中。 复原进去的所有虚拟机数据文件： 7、在一台测试服务器上搭建Hyper-V环境，将复原进去的虚拟机文件连贯到这台服务器上，通过导入虚拟机的形式将复原进去的数据都迁徙到新的Hyper-V环境，而后让用户亲自验证所有虚拟机。 虚拟机导入的过程： 8、用户验证所有虚拟机没有问题后，将所有数据拷贝至用户筹备好的服务器中。用导入的形式将虚拟机导入到用户筹备好的Hyper-V环境中。导入过程中和导入后都没有报错，尝试启动所有虚拟机都没有发现问题。本次数据恢复工作实现。

服务器数据恢复环境：Dell存储服务器，采纳esxi虚拟化零碎，esxi虚拟化零碎里有3台虚拟机；下层iSCSI应用FreeNAS构建，通过iSCSI形式实现FCSAN性能；FreeNAS层采纳UFS2文件系统。esxi虚拟化零碎里有3台虚拟机中的一台虚拟机采纳FreeBSD零碎，存储数据库文件；另外两台虚拟机别离存储网站数据和数据库+工作程序代码。 服务器故障：机房供电不稳导致该存储服务器非正常关机，管理员重启服务器后发现ESXI零碎无奈连贯存储。通过服务器故障排查，发现FreeNAS的UFS2文件系统呈现故障，管理员对UFS2文件系统进行fsck修复并将ESXI零碎连贯到服务器存储上。管理员对下层文件系统及数据进行查看，发现文件系统和存储数据都无奈辨认，于是对vmfs执行了格式化操作，数据失落。须要复原3台虚拟机以及外部的数据。 服务器数据恢复过程：1、首先对FreeNAS层以只读形式进行镜像备份，后续的数据恢复工作都基于镜像文件进行操作，防止对原始数据造成二次毁坏。2、基于镜像文件剖析底层数据。通过剖析服务器数据恢复工程师留神到一个几百G大小的，被命名为iscsidata的大文件。3、持续剖析UFS2文件系统构造，依据UFS2文件系统的存储构造定位到这个名为iscsidata的大文件的iNode数据并进一步进行查看，发现名为iscsidata的大文件被重建过，iNode指针所指向的数据量非常少。在这种状况下，想要进入到vmfs文件系统层进行数据分析和复原必须先剖析出FreeNAS层的相干信息。4、通过剖析失去如下FreeNAS层信息：UFS2文件系统块大小为16kb，segment大小为2kb，柱面组大小为188176kb，数据指针大小为8字节，每个块可包容数据指针数量为2048个。依据下面剖析到的信息能够计算出：一个二级指针块可存储的数据量=2048×2048×16KB=64GB。三级指针块可存储的数据量=64GB×2048=128TB。5、服务器数据恢复工程师打算通过iscsidata文件的三级指针块来复原FreeNAS层的数据，但因为该文件已经被重建，局部指针被重建的数据笼罩，原文件的iNode和重建后的iNode所处地位完全一致，也没有找到其余可用于复原数据的iNode数据。6、依据理论状况，北亚企安数据恢复工程师编写小程收集到了大量二级指针块和三级指针块。7、剖析三级指针块但发现这些指针块都有效，预计是重建时被笼罩了，新的iscsidata文件挂载到ESXi虚拟化零碎后有个VMFS格式化过程，而该版本的ESXi虚拟化零碎应用的是GPT分区，GPT分区会在磁盘最初写入冗余的GPT头和分区表信息数据，会应用iscsidata文件的三级指针块。8、剖析二级指针块，对有大量二级指针块的指向数据进行DUMP，而后再从磁盘中的数据定位到二级指针，这样失去大量DUMP的数据。9、北亚企安数据恢复工程师依据以前钻研出的NTFS和UFS2文件系统构造定位到vmfs层，继而定位到DUMP出的单个64GB文件，最初进行数据组合。10、通过简单的查问和重组，最终胜利复原出了故障服务器存储内的3台虚拟机及虚拟机内的全副数据。 服务器数据验证：将复原进去的数据上传到新搭建的零碎中进行验证，经用户管理员重复验证，确认所有复原进去的数据残缺可用，认可数据恢复后果。

服务器数据恢复环境：服务器内搭建2组raid5磁盘阵列，每组raid5阵列蕴含4个磁盘，2组阵列都划分为lun并组为lvm构造，采纳的ext3文件系统。 服务器故障：始终raid5磁盘阵列中的一块硬盘因为未知故障离线，此时该raid5阵列中的热备盘代替故障盘上线并开始同步数据。在数据同步没有实现时，该阵列中的另一块硬盘呈现离线的状况，热备盘同步失败，该组raid5阵列解体，lvm构造损坏，文件系统不能失常应用。北亚企安数据恢复工程师对离线的2块故障硬盘进行了检测，确认第一块离线硬盘存在物理故障，须要收盘进行物理修复才能够读取，后掉线的硬盘能够辨认读取。 服务器数据恢复计划：北亚企安数据恢复工程师团队依据本案例故障状况制订了针对性的数据恢复计划：1、首先由硬件工程师修复物理故障硬盘，而后将故障raid5中所有硬盘的数据镜像备份。3、剖析镜像文件并重组raid5阵列。4、剖析重组出的磁盘阵列，找回失落的lvm信息并重组lvm卷。5、剖析raid5阵列上的lvm卷，解析ext3文件系统并导出。 服务器数据恢复过程：1、硬件工程师在无尘工作室对故障盘进行收盘操作，收盘检测后发现该硬盘盘片重大磨损，肉眼可见大量划痕，无奈修复，在后续的数据恢复过程中只能做缺盘解决了。2、对故障raid5中其余可辨认的硬盘进行镜像备份，同时对服务器上的另一组raid5阵列也进行镜像备份。3、服务器数据恢复工程师基于镜像文件对底层数据进行剖析，联合EXT3文件系统构造获取到故障raid5阵列的盘序、条带、校验方向等重组阵列必须的raid相干信息，依据这些raid相干信息将故障raid5阵列重组，将无奈修复的物理故障硬盘做缺盘解决。4、重组raid5阵列后，北亚企安数据恢复工程师剖析该重组raid5阵列的底层数据，找到与须要的lvm构造信息并剖析lvm构造，提取出raid阵列中的lvm物理卷lun，重组pv并生成lvm逻辑卷。5、实现重组lvm后解析逻辑卷内的EXT3文件系统并导出所有数据。 服务器数据验证：在本数据恢复案例中，一块硬盘存在重大的物理故障，这块硬盘无奈物理修复，因而会呈现raid构造缺点或者局部文件损坏的状况，好在复原进去的大部分数据通过了验证，只有极少一部分数据损坏无奈修复，然而须要的数据都复原进去，用户通过验证后认可本次数据恢复后果。

服务器数据恢复环境：北京某公司的一台服务器，有一组由3块磁盘组建的raid5磁盘阵列。 服务器故障：服务器在失常运行过程中忽然瘫痪。用户方致电咱们数据恢复核心寻求帮忙，数据恢复工程师达到现场对故障服务器进行了检测，发现导致服务器瘫痪的起因是服务器中一块硬盘因为未知故障离线，存储有重要数据的分区无奈辨认。通过和用户方管理员沟通得悉：在北亚企安工程师到现场之前，服务器管理员曾经对故障服务器进行过一系列救济数据的操作。管理员在发现服务器瘫痪后就重启服务器，故障硬盘从新上线开始同步数据，数据同步到40%左右的时候，管理员感觉异样就强制关机。 服务器数据恢复过程：1、将故障服务器内所有硬盘编号取出，连贯到北亚企安数据恢复平台上，以只读模式对所有硬盘进行镜像备份。备份实现后依照原样把所有硬盘还原到故障服务器中。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、基于镜像文件对所有硬盘底层数据进行剖析，获取到该raid5磁盘阵列相干信息。3、依据raid相干信息重组raid构造并进行抑或校验，后果只有局部数据通过校验。通过服务器数据恢复工程师剖析，产生这种状况是因为离线硬盘从新上线后的同步操作对数据造成毁坏。北亚企安数据恢复工程师尝试不同计划，但最终提取进去的数据都是损坏的，只能尝试是否能修复胜利。4、对存储重要数据的分区进行扫描和剖析，该分区的数据文件目录不可见。只能对自在空间数据页进行扫描并由北亚企安数据恢复工程师进行碎片剖析和重组。对重组出的文件进行残缺度和有效性的验证，验证通过后提取数据。5、用户通过下层利用连贯数据库对提取进去的数据进行可用性验证。通过重复验证，数据库文件能够失常加载，下层利用应用失常。本次服务器数据恢复工作实现。 服务器数据恢复Tip：当服务器因为未知起因故障而导致系统解体或者文件不辨认/不可用时，通常不倡议自觉地在服务器上进行数据分析和数据恢复操作。如果的确对本人的数据恢复技术有自信，必须先对原服务器的所有硬盘数据进行镜像备份，数据分析和数据恢复操作只能在镜像文件上进行，防止操作失误毁坏原始数据，让后续的数据恢复难度减少。

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

服务器数据恢复环境&故障：北京某公司一台配有72块SAS硬盘的服务器，管理员误操作删除了该服务器中的12个lun，这12个lun中蕴含了该公司的客户信息以及其余重要数据，急需复原服务器数据。 服务器数据恢复过程：1、将故障服务器所有硬盘以只读形式做扇区级别的镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、北亚企安数据恢复工程师基于镜像文件剖析服务器底层数据，找到盘头地位的超级块，通过剖析超级块信息获取到磁盘组的起始块信息、磁盘组名称、逻辑组起始块号、raid编号等根本信息。 剖析超级块： 3、通过剖析得悉每个数据块占8个扇区，数据块后附加64字节数据块形容信息，依据这些信息判断出作为校验盘的磁盘并在数据恢复过程中将这些磁盘剔除。0x10：6字节为aggr_data块号如果0x10处为FFFF示意校验块 校验块形容信息样例： 4、在进行盘序剖析时能够依据每块磁盘8号扇区的磁盘信息和磁盘开端的RAID盘序表来确定盘序。a、确定各个磁盘所属aggr组。b、判断组内盘序。数据指针跳转时不思考校验盘，只须要获得数据盘的盘序即可。aggr_raid(磁盘凑近尾部) 依据10H处的VCN块号判断磁盘组内各盘的程序 剖析盘序表： 小贴士：Netapp的节点散布在数量泛滥的数据块内，在数据块内又被对立组织为节点组。每个节点组的前64字节记录零碎数据，而后以192字节为一项来记录各个文件节点。文件节点依据用户级别分为两类：“MBFP”系统文件节点和“MBFI”用户文件节点，数据恢复个别只须要MBFI节点组。 服务器节点样例图： 阐明：头部信息64字节（此头部为数据文件的节点文件块头部，大小为64字节）标记，常量（“MBFP”为元文件的节点标记，“MBFI”为用户文件的节点标记） 5、依据更新序列值获取到最新节点。解析节点中节点类型、逻辑块号、文件数量、文件大小、所占块数量及数据指针，获取节点在节点文件中的逻辑块号，从0开始计数。6、获取目录项，并依据其节点编号，找到对应节点。 获取服务器内对应节点截图： 7、提取服务器数据。a、扫描节点信息。 扫描服务器节点信息： 节点扫描类： 节点扫描程序残缺流程： 在循环扫描结束之后会将所有扫描到的MBFP、MBFI和DOC数据块别离写入到三个文件内，用于后续解决。 b、将节点信息导入到数据库。 将ScanNode扫描失去的MBFI和MBFP、Dir存入数据库以备后续应用。 MBFI导入数据库整体流程： 函数执行结束后查看数据库失去如下信息： 小贴士：Netapp在更改inode节点时不会间接笼罩而是重新分配inode进行写入。单个文件的节点node_uid惟一不变，mbfi_usn会随着节点的变动而增大（失常状况下提取某个文件时应用usn最大的节点）。个别状况下存储划分出的单个节点会作为LUN映射到服务器应用，依据file_size能够确定这个文件的大小，依照文件大小分组后再选取usn最大值的节点，跳转到MBFI文件的offset值偏移地位，取出节点。 节点样例图示： c、提取文件在获取到要提取的文件的Node之后，开始提取块设施文件。提取块设施文件： 初始化结束后，开始提取文件的各级MAP，在本次提取过程中文件大小均大于1T，MAP层级为4，所以须要提取4次。第一级MAP默认只占用1个块，所以在程序内间接提取，后三级MAP在GetAllMap函数内进行提取。通过块号计算数据块地位时，因为NetApp应用JBOD组织LVM，间接用块号除以每块磁盘上的块数可失去以后块所在的磁盘序号（计算机整数除法，抛弃小数邠）；再应用块号取余块数，失去数据块在此磁盘上的物理块号，物理块号乘以块大小，失去数据块偏移地位。 8、块设施文件系统解析。该案例的块设施5T lun用的是aix小机的jfs2文件系统。因而须要解析jfs2文件系统，提取外面的数据库备份文件。7扇区记录lvm形容信息，获取pv大小和pv序号；找到vg形容区，获取lv数和pv数；找到pv形容区，获取pp序号和pp数。 解析文件系统块信息： lv类型及率挂在信息区域： 解析8个由大小1T的lun组成的oralce ASM文件系统，提取其中的数据库文件。 增加8个lT的lun： 解析asm文件系统，提取出数据库文件： 数据验证：北亚企安工程师对提取进去的数据进行检测后没有发现异常，分割用户方工程师亲自进行验证，经重复验证，确认本次复原进去的数据残缺可用。

服务器数据恢复环境：EMC存储，多块stat硬盘组建raid5磁盘阵列，两块热备盘，下层采纳zfs文件系统。 服务器故障&检测&剖析：EMC存储中的raid5磁盘阵列有2块硬盘呈现故障，然而只有一块热备盘被激活，raid5磁盘阵列解体，存储不可用。服务器数据恢复工程师返回现场对故障存储设备进行检测。通过简略排查后确认raid5阵列瘫痪，下层lun无奈应用，2块热备盘只有一块启动。硬件工程师对掉线硬盘进行物理故障检测，均未检测到坏道，磁头也不存在物理故障。在进行数据恢复之前不须要进行物理修复。 服务器数据恢复过程：1、在复原数据之前将故障存储设备上的所有数据以只读形式镜像备份。2、服务器数据恢复工程师基于镜像备份文件剖析故障raid5中的每块硬盘底层数据，发现两块热备盘内没有任何数据，也就是说被激活的那块热备盘也没有同步到任何数据，故障raid5磁盘阵列中的两块热备盘在磁盘离线后没有起到任何作用。想要复原数据须要通过剖析获取到该raid5磁盘阵列的相干信息来重组raid5。3、服务器数据恢复工程师应用北亚企安自主研发的服务器数据恢复工具解析出该组raid5磁盘阵列的根底信息，依据这些信息虚构重组raid5磁盘阵列。将有多块硬盘掉线的磁盘阵列中最早掉线的那块硬盘从阵列中剔除，比对每块硬盘在同一个条带上的数据是否统一，将同一个条带上数据显著不同的硬盘剔除后进行条带校验，直至找到数据恢复的最佳状态为止。4、重组raid5阵列后，服务器数据恢复工程师剖析lun信息，而后应用自主开发的程序解析和导出lun数据的map。5、应用北亚企安自主开发的程序解析和复原下层的文件系统。该故障存储设备下层采纳的是zfs文件系统，服务器数据恢复工程师解析文件系统时发现局部文件系统元文件报错，数据恢复工程师对自主开发的程序进行debug调试，让程序适应本案例数据恢复的需要。6、通过调试发现，导致zfs文件系统解析报错的起因是因为存储设备的忽然瘫痪导致zfs文件系统中某些元文件被毁坏，导致无奈失常解析。服务器数据恢复工程师对损坏的元文件进行手工修复，保障zfs文件系统能够失常解析。7、zfs文件系统解析实现后，服务器数据恢复工程师将故障raid5阵列内的数据残缺导出，由用户方工程师搭建数据验证环境，对复原进去的数据进行验证。通过重复验证，用户原服务器内的所有数据均完全恢复。

服务器数据恢复环境：SUN光纤存储，组建RAID6，划分若干LUN，MAP到不同业务服务器，操作系统是SUN SOLARIS。 服务器故障&剖析：因为须要减少一台新服务器用来运行新增的利用，在原服务器还在线状态下，用户将其中一个lun映射到新服务器上。在执行操作之前，用户没有搞清楚这个行将要映射过来卷实际上曾经map到了solaris生产零碎上的某个lun上了。操作实现之后，这个卷开始进行初始化，本来的solaris上的磁盘报错。用户重启服务器后发现这个卷曾经无奈挂载了。起初在数据恢复之前通过硬件工程师的检测，排除了服务器存在物理故障。用户方工程师检测后执行fsck操作，实现操作后胜利挂载文件系统，然而查看数据时发现大量的数据失落或者文件大小为0，而最新数据全副失落。故障剖析：在失常工作模式下，san调配的卷为独立占用模式，如果用户将其映射给两个或多个操作系统将会导致文件系统一致性出错。如果呈现这种故障，要想复原数据首先要剖析文件系统各个构造的损坏状态。本次数据恢复案例中故障服务器设施的文件系统采纳UFS，所以对任何一个须要复原的文件来说，须要优先查看目录信息、节点、数据区是否失常。如果目录信息、节点、数据区均失常，就能够残缺复原数据。但少数状况下，执行fsck操作后INODE会被革除，即便留下目录信息，也无奈与数据一一对应，这种状况下就只能参考文件外部格局进行类型式的复原。 服务器数据恢复过程：1、残缺备份呈现问题的lun。2、基于备份文件解析文件系统，服务器数据恢复工程师通过剖析发现元文件中的iNode曾经被革除，所以无奈通过还原iNode来复原数据，只能通过文件类型进行数据恢复。3、服务器数据恢复工程师剖析须要复原的特定文件，发现采纳vfs公文零碎的索引文件具备强的类型特色，同时文件中蕴含目录信息。于是，北亚企安数据数据恢复工程师依照公文零碎的索引结构特征编写程序提取数据，实现提取后依据特色重新命名。4、按类型复原数据文件，之后由用户依据索引文件对数据文件进行重新整理。5、通过2天的数据分析和复原操作，北亚企安数据恢复工程师提取了故障服务器内的绝大部分的数据和目录索引文件，通过用户的重复验证，确认所须要的重要数据曾经全副复原。

服务器数据恢复环境：ORACLE Sun ZFS Storage；32块磁盘分为4组，每组8块硬盘，热备盘全副启用。ZFS文件系统，Windows操作系统。 服务器故障&剖析：设施在失常工作时候忽然解体，通过查看排除了断电、进水、异样操作、供电不稳固等因素。用户重启设施无奈进入零碎。ZFS文件系统中，池被称为ZPOOL。ZPOOL的子设施有很多种，其中包含块设施、文件、磁盘等，在本案例中ZPOOL的子设施是三组RAIDZ。通过北亚企安工程师的剖析发现，三组RAIDZ中的两组别离启用了1个热备盘和3个热备盘。在热备盘启用后，第一组RAIDZ内又呈现一块离线盘，第二组RAIDZ内则又呈现两块离线盘。故障场景还原：三组RAIDZ内第一组和二组呈现离线盘，热备盘及时启动替换离线盘；热备盘无冗余状态下第一组RAIDZ又呈现一块离线盘，第二组RAIDZ则又呈现两块离线盘，ZPOOL进入了高负荷状态（每次读取数据都须要进行校验能力失去正确数据）；第二组RAIDZ内呈现第三块离线盘，RAIDZ解体、ZPOOL下线、设施解体。 服务器数据恢复过程：1、重组ZPOOL，追踪数据入口ZFS文件系统治理的存储池与惯例存储不同，是由ZFS治理所有磁盘。惯例RAID在存储数据时依照特定的规定组建池，不关怀文件在子设施上的地位。而ZFS文件系统在存储数据时会为每次写入的数据调配适当大小的空间，并通过计算获取到指向子设施的数据指针。这种个性导致RAIDZ缺盘时无奈间接通过校验失去数据，必须将整个ZPOOL作为一个整体进行解析。 2、手工截取事务块数据，北亚企安数据恢复工程师编写程序获取最大事务号入口。 获取文件系统入口： 3、获取到ZFS文件系统入口后，北亚企安数据恢复工程师编写数据指针解析程序解析地址。 解析数据指针： 4、获取到ZFS文件系统入口点在各磁盘的散布状况后，北亚企安数据恢复工程师手工截取并剖析文件系统内部结构，入口散布所在的磁盘组无缺失盘，可间接提取信息。依据ZFS文件系统的存储构造找出映射的LUN名称，进而找到其节点。 5、提取数据。北亚企安数据恢复工程师编写数据提取程序提取数据。 因为磁盘组内缺盘个数较多，每个IO流都须要通过校验失去，提取进度极为迟缓。与用户沟通后得悉，ZVOL卷映射到XenServer作为存储设备，用户所需的文件在一个vhd内。提取ZVOL卷头部信息，依照XenStore卷存储构造进行剖析后发现这个vhd在ZVOL卷的尾部，通过计算得悉该vhd的起始地位，从此地位开始提取数据。 6、实现数据提取后，验证Vhd外部的压缩包及图片、视频等文件，发现均可失常关上。让用户亲自对数据进行验证，确定文件数量与零碎自动记录的文件数量统一，全副文件可失常关上，服务器数据恢复实现。

数据库数据恢复环境：华为云ECS，linux操作系统；mysql数据库，实例内数据表默认存储引擎为innodb。 数据库故障：在执行数据库版本更新测试时，用户误将本应在测试库测试的sql脚本执行在生产库中，导致局部表被truncate，局部表内大量数据被delete。 数据库复原过程： 1、因为该ECS内有其余业务在失常运行中，为防止被truncate表的底层数据不被毁坏，首先镜像备份mysql数据库data目录所在分区。 2、因为须要复原的被truncate表不存在大字段类型值和myisam引擎表，数据恢复工程师应用工具扫描数据段并下载复原数据所必须的mysql数据库段碎片。因为innodb引擎表的数据恢复必须依赖表构造信息，mysql的表构造信息存储于对应表名的.frm文件内。通过检测发现在本案例中的.frm文件完整，可间接应用。下载须要的表对应的.frm文件。 3、读取数据段内零碎表信息，获取须要复原的表在零碎表内的注册信息。 4、在下载实现的数据段文件内提取对应于各表的数据页，解析对应表的.frm文件获取到该表的表构造信息。通过表构造信息获取到底层数据调配规定，依照规定拆分数据段内二进制数据并对不同类型进行字符展现转换（各类整型、浮点型、工夫型等），实现数据段到sql语句的转换。 5、复原被delete数据的表，过程和复原truncate表的相似，不同点在于解析数据时须要提取被标注为“delete”的记录。 6、依据解析出的表构造信息在环境中的mysql实例内创立表，并将复原出的数据导入。 7、因为间接从底层抓取出的记录可能存在主键不惟一（引擎在存储时产生的长期记录）和记录反复（缓冲段）以及乱码（扫描数据段时呈现特征值匹配胜利但不属于该表的数据段）等状况，提取出的记录可能存在异样，须要北亚企安数据恢复工程师手动解决。 8、开启远程桌面，由用户验证数据的准确性和残缺度。通过重复验证，truncate表和delete记录的表都残缺复原。

服务器数据恢复环境：某影音制作公司一台infortrend某型号存储设备；12块硬盘组建raid6磁盘阵列，共一个lun映射到WINDOWS零碎；在WINDOWS零碎上，划分了一个GPT分区。 服务器故障&剖析：未知起因该infortrend存储设备不可拜访，用户查看服务器发现故障存储raid6阵列中有3块磁盘离线，强制上线离线磁盘后又进行了rebuild，实现强制上线的操作后发现分区不能关上，数据无法访问。用户找了一家当地数据恢复服务器商进行数据恢复，后果只复原局部数据。Raid6磁盘阵列能够反对2块磁盘同时离线，故障存储内有3块磁盘先后呈现故障离线，用户将先离线硬盘进行上线操作，这时阵列会将所有数据进行算法同步，导致无奈失常读取数据，服务器解体。 服务器数据恢复过程：1、对故障存储所有硬盘以只读形式做扇区级的镜像备份，对于有物理故障的硬盘由硬件工程师解决后再做镜像备份。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、剖析该infortrend存储所应用的的RAID6算法，依照故障存储RAID6算法对12块磁盘做C(12，2)共66种缺2盘状况的组合。通过人工或程序断定最可能的缺盘状况的组合。3、搭建虚构RAID，依照剖析出的缺盘状态、盘序、块大小、校验方向、RAID6算法等raid相干信息进行附加。4、对虚构RAID进行GPT分区构造解释，而后进行文件系统解释，确定算法是否正确。如不正确，调整算法，直到失去称心后果。5、按文件或扇区形式将数据迁徙到另一筹备好的存储设备中，复原工作实现。

服务器数据恢复环境&故障：某品牌730服务器，linux操作系统。机房意外断电导致服务器局部文件失落。 服务器数据备份&故障剖析：1、将linux服务器连贯到筹备好的数据恢复服务器上，以只读模式对服务器数据做镜像备份，备份实现后将服务器偿还用户。后续的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。2、通过镜像文件查看故障服务器底层，发现故障服务器的数据目录项因为意外断电被毁坏。3、排查被毁坏的目录项信息，发现一部分目录项数据尽管被毁坏但能够修复。4、持续排查后发现数据区索引也被革除，这种状况须要北亚企安数据恢复工程师在自由空间中去匹配&拼接碎片来复原数据。 服务器数据恢复过程：1、提取lost+found文件夹下的文件名称。2、逐个配对失落文件的文件目录节点号与提取的文件夹名称，剖析失落的目录构造。3、依据文件系统构造定位至底层空间绝对应地位，扫描该地位并提取合乎失落的目录构造信息。4、将提取的失落目录构造信息与目录项节点号对接并记录到数据库内。5、将lost+found里找到的文件记录号与数据库记录的记录号进行配对，提取数据。6、通过北亚企安数据恢复工程师和用户的重复核检，确认复原数据残缺可用。 服务器平安Tips：1、保障机房供电稳固，尽量减少供电异样对服务器及存储设备的影响；2、为要害的服务器和存储配置UPS，在机房意外断电的状况下保障外围业务零碎能持续维持失常工作，为其余应急计划的施行争取时间；3、对于应用工夫长的服务器应定期进行安全检查，对其整体运行状态进行评估，是否对其进行硬件及零碎的降级；4、提前制订突发数据劫难的应急解决计划，缩小数据劫难带来的损失。

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

服务器数据恢复环境&故障：某品牌服务器，搭建raid5磁盘阵列。用户误操作删除服务器上的卷。通过检测发现服务器不存在物理故障，能够从raid5磁盘阵列层面进行数据恢复。 服务器数据恢复过程：1、对故障服务器所有硬盘以只读形式做镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行， 防止对原始数据造成二次毁坏。2、剖析超级块信息，获取到raid5阵列的逻辑起始块地位号，记录raid5阵列起始块地位。3、去除raid5阵列的校验盘。通过剖析发现raid5阵列数据块大小为8扇区，每个数据块后有一个附加的大小为64字节的数据块形容信息。所以在底层找到0X10地位为FFFF的就是要找的校验块。 4、剖析aggr盘序。已知raid5阵列中的数据块大小为8扇区，因而依照每块磁盘的8号扇区进行盘序剖析，确定每块磁盘各自归属的组，还原磁盘在各自的组内的排序。5、剖析raid磁盘阵列节点信息。服务器的节点散布在不同的数据块内并组成节点组，后面曾经剖析出每64字节记录一些零碎数据，之后用192字节为一项来记录各个文件节点。文件节点依据用户级别可分为两类：“MBFP”系统文件节点和“MBFI”用户文件节点，在复原数据时个别只取MBFI节点组即可。 头部信息64字节（此头部为数据文件的节点文件块头部，大小为64字节）“MBFP”为元文件的节点标记，“MBFI”为用户文件的节点标记6、依据更新序列值获取到最新节点。解析节点中节点类型、逻辑块号、文件数量、文件大小、所占块数量及数据指针。获取节点在节点文件中的逻辑块号，从0开始计数。7、获取目录项，并依据其节点编号，找到对应节点。 8、依据剖析获取到的raid阵列信息重组raid5阵列，北亚数据恢复工程师编写小程序提取服务器内的数据。 服务器数据验证：北亚数据恢复工程师在服务器上搭建了与原始服务器雷同的环境，在下层利用内验证数据无误后交付给用户，由用户亲自验证，通过用户重复验证后确认数据残缺可用。

服务器数据恢复环境：某单位一台某品牌DS系列服务器连贯4个扩大柜；50块磁盘组建两组RAID5，其中一组由27块磁盘组建的RAID5寄存的是Oracle数据库文件；下层一共划分11个卷。 服务器故障：磁盘故障导致寄存Oracle数据库文件的RAID5解体，服务器不可用。 服务器数据恢复过程：硬件工程师先对故障服务器的27块磁盘进行硬件故障检测，发现其中的2块磁盘存在坏道，SMART谬误冗余级别曾经超过阈值。对另外的25块无硬件故障的磁盘做全盘镜像，对2块有坏道的磁盘进行复原并生成镜像文件。收集故障服务器的日志信息并进行剖析，查明两块存在坏道的磁盘掉线先后顺序，用后掉线的磁盘进行数据恢复。通过北亚数据恢复工程师团队会诊最终敲定两套数据恢复计划：计划一：把故障服务器所有硬盘都备份后通过该品牌自带存储管理软件强制上线。计划二：通过剖析硬盘底层获取raid相干信息，利用获取到的信息重组RAID，提取数据并从新加载oracle数据库，调试下层利用。执行第一套计划，先在模拟器上测试，测试实现后通过该品牌自带的存储管理软件进行强制上线。强制上线后发现raid处于降级状态，这时设置好热备盘上线并开始同步数据，同步完之后发现下层的卷曾经能够间接应用，所有数据可见，下层利用可失常应用。尽管下层的卷能够应用，数据也都可见，然而出于平安思考，北亚数据恢复工程师将卷里的文件都拷贝进去移交给用户，通过用户重复测试后确认复原数据残缺可用。 Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

服务器数据恢复环境&故障：某公司服务器，装备24块FC硬盘，两块硬盘呈现故障掉线，导致服务器下层的卷无奈挂载。 服务器数据恢复过程：1、查看服务器硬盘状态发现有两块硬盘离线，将服务器内的所有硬盘做好标记取出并以只读形式做扇区级别的镜像备份。2、镜像过程中，数据恢复工程师发现在IBM storage manager和硬盘SMART状态中均无报错的1号磁盘存在坏道，另外的2块磁盘也散布大量不法则的坏道。3、依据坏道列表应用工具定位到指标镜像文件进行检测，发现局部ext3文件系统要害源数据信息曾经被坏道毁坏，只能通过同一条带进行xor和依据文件系统上下文关系的形式手动修复损坏的文件系统。4、对故障服务器的文件系统和日志进行逆向剖析，获取到故障服务器的盘序信息、raid块大小、raid校验形式等重组raid的必须信息，通过这些raid相干信息虚构重组故障服务器的raid阵列。5、重组实现后北亚数据恢复工程师进一步剖析服务器文件系统的根底信息，提取出数据库dmp文件。6、通过数据库dmp文件复原数据库时呈现“imp-008”谬误，通过对数据库认真排查，发现从重组raid阵列中提取出的dmp文件异样，导致了dmp导入数据时报错。7、服务器数据恢复工程师从新剖析raid阵列根底构造和文件系统构造并从新提取dmp文件及dbf原始库文件，再次尝试导入dmp文件并测验，测验后果失常。8、将dmp文件移交给用户亲自验证，经用户重复验证确认数据残缺可用。9、北亚服务器数据恢复工程师将数据导入搭建好的新服务器环境内进行验证没有发现问题，本次服务器数据恢复实现。

服务器数据恢复环境：一台服务器上5块硬盘组建raid5磁盘阵列，用于存储公司数据，无备份。 服务器故障&剖析：服务器上一块硬盘故障掉线，用户延聘一家运维公司对服务器进行保护，运维公司技术人员在没有理解分明服务器原始环境的状况下，将服务器上没有掉线的4块硬盘重新组建为一组新的raid5阵列，导致服务器原有数据全副失落。本案例中导致服务器数据失落的起因就是重建raid5这个操作。用户服务器上原始阵列是raid5，即便有一块硬盘掉线也不会影响服务器的失常运行和数据的完整性。但运维公司技术人员在没有搞清楚原始环境的状况下应用剩下4块没有掉线的硬盘重建raid5阵列，重建raid5磁盘阵列会导致全盘重建校验块，意味着原始raid5阵列的数据必定会被毁坏。通过北亚数据恢复工程师初步检测，运维公司技术人员通过4块硬盘组建的raid5是双循环，块大小为64，条带化校验次数为16；故障服务器内原始的5盘raid5阵列也是双循环，块大小为12，条带化校验次数为16。由此能够推断：服务器内重建raid5阵列的4块硬盘中每隔3M的数据将呈现1M的原始数据被毁坏。要复原服务器内原始raid5的数据就要剖析掉线的那块硬盘，通过比照5盘raid阵列和4盘raid阵列的差别，利用掉线硬盘数据补缺其余4块硬盘中被毁坏的原始数据，最初重组raid，解释文件系统并导出文件即可。因而本案例复原数据的残缺度取决于掉线硬盘的数据量。 服务器数据恢复过程：1、对故障服务器内的所有硬盘以只读形式做扇区级别的镜像备份，后续的数据分析和复原操作都基于镜像文件，防止对原始数据造成二次毁坏。2、剖析镜像文件，获取服务器数据被毁坏之前原始raid5阵列的raid构造和毁坏之后新组建raid5阵列的raid构造。3、比照数据被毁坏前后的raid阵列构造，剖析raid构造差别，北亚数据恢复工程师编写修改程序并提取数据。4、依照故障服务器内原始raid5磁盘阵列构造虚构重组raid5阵列，生成镜像文件。5、提取掉线硬盘内的数据，利用掉线硬盘数据补全虚构重组的raid5阵列数据，对文件系统谬误进行修改。6、将修复后的数据导入到新空间并进行验证，验证无误后交由用户亲自验证。7、通过用户客户重复验证，确认复原进去数据残缺可用，本次数据恢复工作实现。

MongoDB数据库数据恢复环境：MongoDB数据库部署在一台虚拟机上，虚拟机操作系统为Windows Server2012。 MongoDB数据库故障&剖析：因为业务倒退需要，须要对MongoDB数据库内的文件进行迁徙，在MongoDB服务开启的状态下用户将数据库文件复制到其余分区，将MongoDB数据库之前所在分区进行了格式化操作。迁徙后用户发现数据库文件无奈应用，将数据库文件拷贝回原分区后MongoDB数据库仍然无奈失常应用，报错“Windows无奈启动MongoDB服务（位于 本地计算机 上）谬误1067：过程意外终止。” Tips：在MongoDB服务开启状态下拷贝数据库文件会导致mongod.lock和WiredTiger.lock这两个文件拷贝出错，如果呈现这种状况，咱们能够在拷贝文件中找到这两个文件并删除，而后再次尝试启动MongoDB数据库，在数据库重新启动后会主动从新生成这两个文件，数据库即可失常应用。数据库数据恢复工程师检查用户迁徙出的数据库文件后没有找到_mdb_catalog.wt文件。mdb_catalog.wt文件是专门用于存储MongoDB数据库中所有汇合元数据的文件，数据库启动时所必须读取的相干信息都存储于mdb_catalog.wt文件中。所以，北亚数据恢复工程师推断导致MongoDB数据库启动报错的起因应该是mdb_catalog.wt文件失落，数据库无奈读取汇合对应的WT table名字，汇合的创立选项，汇合的索引信息等元数据。 MongoDB数据库数据恢复过程：1、扫描MongoDB数据库分区的底层数据，后果没有找到对于_mdb_catalog.wt文件的信息。屡次调整扫描形式进行扫描依然无奈查找到_mdb_catalog.wt的相干信息，数据恢复工程师判断该文件已被笼罩，无奈通过_mdb_catalog.wt文件修复MongoDB数据库。2、数据恢复工程师调整策略，因为该MongoDB数据库是基于WiredTiger存储引擎，于是北亚数据恢复工程师在Windows环境下编译出可执行的wt工具。 3、借助编译后的wt工具荡涤回写MongoDB数据库汇合文件内所有数据，读取数据后果并写入到文件中。4、创立一个全新的MongoDB数据库并创立相应数据量的汇合，将文件逐个写入到汇合中，查问数据集并重建索引信息。5、通过查问汇合中的记录，确定记录类型，重建汇合索引，汇合复原实现后能够失常查看其中数据： 6、帮助用户对全副汇合进行索引重建后，由用户对MongoDB数据库进行查问验证，确定数据无误，本次数据恢复工作实现。

服务器数据恢复环境：某品牌服务器，12块硬盘组成raid5磁盘阵列，存储一般文件。 服务器故障：机房供电不稳固导致服务器断电，管理员重启服务器后发现服务器无奈失常应用。依据用户形容，北亚服务器数据恢复工程师推断服务器故障起因是意外断电导致的raid模块损坏。 服务器数据恢复过程：1、数据恢复工程师对故障服务器所有硬盘做物理故障检测，后果所有硬盘读取失常，没有发现存在物理故障。2、服务器数据恢复工程师将故障服务器所有硬盘以只读形式做扇区级别的镜像备份，后续的数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。3、基于镜像文件做raid构造剖析，通过剖析获取到raid相干信息（硬盘排列程序、阵列校验形式、硬盘数据块大小等）并利用这些raid相干信息重构raid阵列。4、对重构的raid阵列进行逻辑校验，校验通过并且所有参数正确无误。5、让用户亲自验证，通过重复验证后用户确定复原进去的数据残缺可用。6、由数据恢复工程师帮助用户将数据迁徙到提前准备好的服务器。 Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

服务器存储数据恢复环境：某公司一台EMC存储，12块硬盘组成raid5，2块热备盘；Zfs文件系统。 服务器存储故障：硬盘故障导致存储解体。 服务器存储数据恢复过程：1、对故障存储所有硬盘进行物理故障检测，未发现有坏道或者其余物理故障。将故障存储所有磁盘以只读形式做镜像备份，备份实现后将所有硬盘依照原样复原到故障存储并交还给用户，后续所有操作都在镜像文件中进行，防止对原始数据造成二次毁坏。2、故障存储中的硬盘组建的是raid5磁盘阵列，至多须要2块硬盘掉线才会导致raid5解体。后面物理故障检测后并未发现硬盘存在物理故障，所以只需通过底层剖析raid构造并虚构重组raid即可复原数据。3、通过剖析镜像文件，北亚数据恢复工程师获取到故障存储中raid5阵列的硬盘盘序、条带大小、散布法则等。同时发现故障存储原始raid5阵列中的两块热备盘均未写入任何数据。4、依据剖析取得的riad5信息，通过北亚自研工具虚构重组aid5阵列。5、剖析LUN在RAID阵列中的调配信息和LUN调配的数据块MAP。6、利用北亚自研的zfs文件系统解析工具解析lun文件系统，在解析过程中发现局部zfs文件系统元文件毁坏，北亚数据恢复工程师手动修复这些被毁坏的文件，直到能全副失常解析zfs文件系统。7、Zfs文件系统解析实现后，持续解析并导出故障存储中的文件节点、目录构造。8、数据恢复工程师验证导出的数据未发现错误。把数据交付给用户亲自验证，通过重复验证用户确认数据残缺可用。

vsan数据恢复环境：一组4台服务器搭建vsan集群；每台服务器配置有2组别离由6块硬盘组成的磁盘阵列，下层是虚拟机文件。 vsan故障：在运行过程中，某一个节点的一块硬盘离线，vsan平安机制启动，开始重构&迁徙数据。在数据迁徙过程中机房意外断电，数据重构失败，服务器重启，该节点的另一组磁盘阵列中的2块磁盘因为异样断电引发故障离线，从而让整个分布式存储瘫痪，下层所有虚拟机无法访问。 vsan数据恢复过程：1、把+vsan集群所有节点上的硬盘以只读形式做镜像备份，备份实现后将硬盘依照原样还原到原始环境，后续的数据恢复操作都基于镜像文件进行，防止对数据造成二次毁坏。2、基于镜像文件剖析底层数据，剖析下层虚拟机所在磁盘地位的数据分布信息。应用北亚自研的针对vsan架构下的虚拟化数据恢复辅助程序验证数据分布信息的准确性。3、再次剖析每个节点上的两个磁盘阵列，搞清楚每个磁盘阵列外部的硬盘对应关系。4、在每块硬盘上获取磁盘的UUID和所在磁盘阵列的UUID。5、依据每个磁盘阵列中的容量盘的组件信息中记录的组件的MAP地位提取组件位图。6、依据组件位图提取组件数据和缓存数据。7、依据组件的形容信息获取组件所属对象及组件程序并合并组件为对象。8、依据对象提取数据。提取出所有数据后经服务器数据恢复工程师验证无异样，分割用户亲自进行验证，确认所有数据残缺可用，本次数据恢复工作实现。

服务器数据恢复环境：磁盘柜+RAID卡搭建riad5磁盘阵列;Linux操作系统；总共一个LUN，划分两个分区;：sdc1分区通过LVM扩容的形式退出到了root_lv中，sdc2分区格式化为XFS文件系统。 服务器故障：用户为服务器重装系统后发现分区产生扭转，原先的sdc2分区失落，无法访问。 服务器数据恢复过程：1、对故障服务器所有硬盘做只读模式的镜像备份，后续的数据分析和数据恢复操作都在备份文件上进行，防止对原始数据造成二次毁坏。2、剖析镜像文件获取故障服务器raid5磁盘阵列的硬盘程序、条带大小等相干信息。3、基于获取到的raid信息对虚构重组原始raid5磁盘阵列。4、在虚构重组进去的raid阵列中定位xfs文件系统的分区起始地位。5、校验xfs文件系统的完整性及正确性，没有发现异常。6、对xfs文件系统的超级块构造进行修复。 修复实现的超级块： 7、修复xfs文件系统中失落的节点及目录项。 修复实现的根节点： 重做的目录项： 8、实现修复后北亚数据恢复工程师编写程序解析xfs文件系统并提取其中的数据。在本次服务器数据恢复过程中，服务器数据恢复工程师检测失落的xfs文件系统后发现xfs文件系统头部的超级块及局部节点、目录项失落。服务器数据恢复工程师依据超级块备份及xfs文件系统中的目录树结构修复超级块，对失落的节点、目录项进行修补、重构之后，xfs文件系统中的数据就能够复原进去。 修复实现的目录构造： 9、用户对复原进去的数据进行重复验证无误，本次数据恢复实现。

服务器故障：用户误操作将linux文件系统误装入到Ocfs2文件系统的数据卷上，导致原始Ocfs2文件系统被格式化为Ext4文件系统。因为Ext4文件系统每隔几百兆就会写入文件系统的原始信息，所以本案例中的原始Ocfs2文件系统中的数据可能受到肯定水平的毁坏，但不会太重大。 服务器数据恢复过程： 1、将故障服务器中的所有硬盘以只读模式映射给备份服务器，将映射到备份服务器中的数据做镜像备份。做完镜像后将所有硬盘依照原样还原到故障服务器，之后的数据恢复操作均在镜像文件上进行，防止对原始数据造成二次挫伤。 2、找到&剖析ocfs2文件系统的超级块，通过剖析获取到ocfs2文件系统的根本构造信息。通过用户提供的虚构磁盘文件名称找到虚构磁盘文件的目录项和对应的一级索引项和二级索引项。3、利用北亚自主开发的ocfs2文件系统解析程序对备份数据进行文件系统解析。ocfs2文件系统的索引项构造如下： 一级索引项： 二级索引项： 4、修复损坏的Ocfs2文件系统。对原始Ocfs2文件系统做一致性检测，北亚数据恢复工程师对损坏的区域进行人工修复。5、应用北亚自主开发的针对Ocfs2不残缺文件系统的解析工具解析已修复的Ocfs2文件系统。6、依据对Ocfs2文件系统剖析后果，北亚数据恢复工程师编写对应的数据提取程序复原每一个虚构磁盘文件，对复原进去的每一个虚构磁盘文件做一致性检测。7、解析复原进去的虚构磁盘文件，验证虚构磁盘文件是否有谬误并尝试修复。8、复原虚构磁盘文件中的用户文件，对已复原的用户文件做一致性检测并尝试修复损坏的文件。9、验证比拟重要的虚拟机，虚拟机大多都能够开机进入到登录界面。有小局部虚拟机开机蓝屏或开机检测磁盘，通过光盘修复之后都能够失常启动。 局部虚拟机开机如下： 其中有一台虚拟机磁盘文件复原之后，通过解析发现该虚拟机中没有数据。持续剖析该虚构磁盘文件，发现该虚构磁盘文件索引项存在，然而索引构造并不多，数据量也很少，揣测可能存在人为清零或批改的状况，也可能该虚拟机本来就没有多少数据。 10、验证重点虚拟机中的数据库，发现数据库都失常。局部数据库与应用程序连贯呈现问题，用户分割应用程序厂商技术人员进行修复之后，数据库都能够失常应用。 11、通过数据恢复工程师和用户的亲自验证确认数据没有问题后，把所有复原进去的数据移交给用户。

数据库复原环境：操作系统：windows server；数据库：win_oracle_x64。 数据库故障&剖析：oracle数据库误truncate table，备份无奈应用。oracle数据库误操作导致数据失落是比拟常见的一种故障，如果有备份只须要复原备份数据即可，咱们核心数据恢复工程师接到的case多是无备份或者备份无奈应用、还原报错等。首先介绍下Truncate工作原理：失常状况下oracle会通过Segment Header及数据字典对表更新Data Object ID，实际上存储数据局部的块并未被批改，如果被truncate，那么oracle在读取全表数据时会因为数据字典和Data Object ID与理论存储的数据块内容不统一而不会读取被truncate的内容记录。 数据库数据恢复过程：本次案例演示中，北亚数据恢复工程师结构了一个雷同环境下的相似故障。1、用Scott用户创立表emp1，间断屡次复制emp表，而后truncate表emp1。此时查问该表，数据库中该表的记录为0条。 2、基于oracle数据库文件底层剖析system表空间文件，找到truncate表的原始数据所在的地位。 3、解析表所在的数据文件数据库，找到truncate的数据并将truncate的数据插入到数据库中。通过解析system01.dbf文件，找到truncate的数据所在的地位，继而找到被删除的数据。解析表所在的数据文件，而后将truncate的数据插入到数据库中。 4、在数据库中查找被truncate的数据，后果发现被truncate的数据曾经复原，备份数据。 5、Exp导出scott用户。

服务器数据恢复环境：EMC某型号存储；8块硬盘组成raid5磁盘阵列。 服务器故障：raid5磁盘阵列中2块硬盘离线，服务器解体，下层利用不可用。 服务器数据恢复过程：1、数据恢复工程师将故障存储设备内的所有硬盘镜像备份，在镜像备份过程中没有发现离线硬盘有物理故障，间接镜像故障存储中所有硬盘。备份实现后把硬盘依照原样装回故障存储设备中，后续的数据恢复操作都在镜像文件进行，防止对原始数据造成二次毁坏。2、数据恢复工程师开始基于镜像文件对底层数据进行剖析，计算出故障存储设备中原raid5的硬盘盘序、raid条带大小等raid信息，通过这些信息虚构重组raid。3、因为故障存储中的LUN是基于RAID组的，把raid虚构重组进去后，北亚数据恢复工程师开始剖析LUN在RAID组中的调配信息以及LUN调配的数据块MAP。4、依据获取到的对于LUN的信息，数据恢复工程师应用北亚自研的raid恢复程序解释LUN的数据MAP，导出LUN的所有数据。5、应用北亚自研的文件系统解释程序对导出的lun进行文件系统解释，在文件系统解释过程中呈现报错，数据恢复工程师剖析报错内容并调试文件系统解释程序，通过剖析与调试确认是因为故障存储中某些元文件损坏导致解释zfs文件系统程序报错。6、数据恢复工程师手动修复损坏的文件，直至zfs文件系统能够被失常解析。7、屡次修复和解析zfs文件系统后对最新数据进行验证，验证无误后分割用户亲自对复原进去的数据进行验证，确认数据残缺可用。 Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

服务器故障：某品牌Storwize系列存储中raid5阵列有一块硬盘呈现故障离线，热备盘启用替换离线盘，开始同步数据。这时与离线盘同一组Mdisk中的另一块磁盘故障离线，热备盘同步失败，这组Mdisk生效，整个通用卷无奈应用。用户分割咱们数据恢复核心寻求帮忙。本案例中用户要求复原的次要是dcm图像文件。 服务器数据恢复过程： 1、存储设备关机、切断电源。以只读形式对故障存储设备中所有硬盘以只读形式做扇区级别的备份。备份实现后将硬盘依照原样复原到故障原存储设备中，后续所有数据恢复操作均在镜像文件上进行，防止对原始数据造成二次毁坏。 2、剖析&重组Mdisk。A、从用户那里获取到故障存储设备的原始配置信息，将硬盘依照Mdisk组分类。B、剖析每一组Mdisk中的所有硬盘，获取到相干raid信息。C、虚构重组Mdisk。 3、剖析pool。A、剖析所有Mdisk，获取到pool的相干信息。B、虚构重组pool。 4、修复文件系统。A、对NTFS文件系统的正确性及完整性进行校检。B、北亚数据恢复工程师修复NTFS文件系统。 5、解析文件系统并提取数据。A、解析NTFS文件系统。B、生成卷中的全副数据。 6、验证数据。由用户亲自对复原进去的数据进行验证，如果发现问题则反复上述步骤，直至所有数据残缺可用。

服务器数据恢复环境：某品牌X系列服务器；linux操作系统；4块SAS接口硬盘组建raid5磁盘阵列。 服务器故障&检测：服务器运行过程中因为未知起因忽然瘫痪，用户为故障服务器重新安装操作系统，装置实现后发现数据失落。分割咱们数据恢复核心寻求帮忙，须要复原的数据包含：数据库、办公文档、代码文件等。数据恢复工程师检测了故障服务器，发现用户的重装系统操作导致逻辑卷被批改，文件系统被毁坏，呈现空白超级块。 服务器数据恢复过程：1、剖析服务器底层数据，北亚服务器数据恢复工程师依据节点间的互相关联关系剖析获取到被毁坏前的节点信息并修复节点。2、调整文件系统中的文件，生成B+树并导出所有节点。3、排查导出的节点，革除有效节点，从新排序生成对应的地位信息。4、依照对应地位信息查问节点，生成树的索引信息，而后生成超级块信息。5、在虚拟机下创立快照，将修复后的数据挂载到新创建好的快照下，这时曾经能够看到文件内容。6、北亚数据恢复工程师在虚拟机环境下持续修改文件目录地位、名称等信息，查找&修复文件头、文件标记地位，复原出所有数据。7、分割用户方亲自验证数据的完整性、正确性。通过重复验证，用户确认复原的数据残缺、正确，可用。

vSAN存储数据恢复环境：某公司一台vSAN分布式文件系统存储设备；VSAN存储采纳了超交融架构，存储内总共有24块硬盘。 vSAN存储故障&初检：因为未知起因关机重启，逻辑架构呈现重大故障，下层虚拟机瘫痪，存储数据失落。首先对故障存储设备上的数据做镜像备份，后续的数据分析重组和提取只在镜像文件上进行，防止对原始数据的二次毁坏。数据恢复工程师首先将故障存储设备断电，将存储内的硬盘编号&取出，对每一块硬盘做扇区级镜像备份。在镜像过程察看硬盘是否存在物理故障，备份实现后没有发现硬盘存在物理故障。备份实现后，通过对底层数据的简略剖析，北亚数据恢复工程师初步判断故障存储下层的虚拟机组件信息毁坏，但不重大，复原数据所需的关键性信息都失常。 vSAN存储数据恢复过程：1、针对本案例故障状况，北亚数据恢复工程师编写数据扫描和重组工具扫描故障存储底层所有数据碎片并重组，提取出所有组件ID以及对象ID。2、利用组件ID和对象ID追溯数据碎片的逻辑地位，提取所有数据碎片。3、重组、拼接所有提取进去的数据碎片并生成残缺的vmdk文件。4、剖析vmdk文件并合并快照父盘，解析快照和vmdk文件，提取可用数据。5、提取所有数据后，搭建与故障存储环境雷同的数据验证环境，分割用户亲自验证。通过重复验证，确定复原进去的数据残缺可用。

服务器数据恢复环境：某公司一组服务器：磁盘柜+raid卡，raid5磁盘阵列；linux操作系统+XFS文件系统，共3个分区。 服务器故障：服务器重装操作系统，实现操作后用户发现服务器的磁盘分区呈现问题：一个分区隐没，其余分区不可拜访。 服务器数据恢复过程：1、为防止对原始数据造成二次毁坏，北亚数据恢复工程师对故障服务器所有硬盘数据进行了盘对盘的镜像备份，后续的数据恢复操作都基于镜像实现。2、剖析raid&获取raid相干信息：服务器硬盘盘序、raid阵列条带大小、raid块排列程序等。基于剖析获取到的重组raid所需信息虚构重组raid。3、在重组出的raid阵列内定位分区起始地位并提取出整个xfs文件系统的数据，验证提取数据的完整性和准确性，均没有发现异常。4、修复xfs文件系统的超级块构造。 修复实现的超级块： 5、修复xfs文件系统中失落的节点及目录项。 修复实现的根节点： 重做的目录项： 6、修复实现后北亚数据恢复工程师编写程序解析xfs文件系统并提取其中的数据。 7、数据恢复工程师验证提取的文件无误后分割用户亲自对数据进行验证，确认后果残缺、精确、可用。

服务器数据恢复环境：一台应用NTFS文件系统的服务器；7块硬盘组成了一组raid5磁盘阵列。 服务器故障&初检：raid5磁盘阵列磁盘故障离线导致服务器瘫痪。用户在解决掉线磁盘时只增加新的硬盘rebuild，并没有将掉线的3块硬盘从阵列中拔掉。硬件工程师对故障服务器中所有硬盘进行了物理检测，没有发现硬盘物理故障，只好交由服务器数据恢复工程师对所有硬盘做全盘镜像&剖析。 服务器数据恢复过程：1、对所有硬盘镜像备份后，服务器数据恢复工程师剖析服务器raid构造。故障服务器中的硬盘每512字节多加了一个8字节的校验，也就是说每扇区520字节。北亚数据恢复工程师编写了一个小程序将8字节的校验去掉，不便后续的数据恢复。2、实现磁盘转换后开始剖析RAID的构造。因为多了3块离线盘（故障离线后没有插入），须要比拟每块磁盘。因为其中会有两块磁盘后面的一部分雷同，这两块后面局部雷同的磁盘中有一个是旧盘，旧盘数据量没有新盘多，能够排除旧盘。3、因为故障服务器应用的是NTFS文件系统，应用MFT就能够找到RAID构造。搞清楚RAID构造后发现这不是一个一般的RAID5，而是一个双循环，无奈通过惯例伎俩重组RAID。4、通过其余办法重组RAID后发现数据不是新的。揣测可能是RAID5掉线第一块硬盘时用户没有及时发现，没有及时增加新的硬盘做rebuild，服务器运行一段时间后又有一块硬盘掉线了，造成整个RAID不可用。5、服务器数据恢复工程师应用穷举+校验的办法进行剖析：假如某个磁盘掉线，踢掉该磁盘后重组RAID，不必生成全副的数据，只生成后面几个G的数据，而后通过查看这个索引表的位图信息是否正确就能够判断此RAID是否正确。如果索引表的位图信息正确，生成此RAID数据即可实现RAID的重组。6、数据恢复实现后由用户亲自核检，数据残缺可用，本次数据恢复实现。 Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

分布式存储数据恢复环境：16台物理服务器，每台物理服务器上无数台虚拟机；虚拟机上配置分布式，下层部署hbase数据库和hive数据库。 分布式存储故障&剖析：误删除数据库底层文件，数据库不能应用。须要复原hbase和hive数据库。通过现场对用户环境的检测，数据恢复工程师发现虚拟机还能够失常启动，虚拟机上的数据库块文件失落。块文件失落之后没有新的数据写入操作，底层的数据损坏可能性比拟小。 分布式存储数据恢复过程： 1、备份。对物理服务器底层做备份。通过网络间接备份虚拟机底层磁盘文件。筹备一台服务器，以只读形式挂载所有服务器硬盘，应用磁盘备份工具进行扇区级别的备份。 2、剖析块文件构造。剖析每个虚拟机磁盘的块文件&文件底层的聚合形式&每个磁盘中数据的散布状况。 3、剖析Block文件key。定位&提取并解析数据库文件中key信息，整合数据库文件key信息。 4、拼接Block文件。依据Block文件的key信息提取文件片段，拼接提取进去的Block文件片段并校验拼接进去的Block文件的正确性。 5、导入Block文件。校验提取出的Block文件完整性及正确性并把提取进去的Block文件导入到hbase和hive数据库中。 6、验证数据。在北亚数据恢复工程师的帮助下，由用户对复原进去的数据进行验证。如果发现问题，从新测验上述所有过程。 北亚数据恢复服务：1、整个过程不会对原盘进行任何写入操作。2、尽可能保障操作可逆，确保人力可控范畴内操作可回溯。3、提供前期数据保存和服务跟踪。4、所有操作都是在有备份的状况下进行，若不胜利不影响其余计划。

SQL server数据库故障：SQL server数据库和备份文件被加密，无奈应用。数据库MDF、LDF、log日志文件名字被批改。 SQL server数据库数据恢复过程：1、首先对故障数据库所波及到的硬盘进行镜像备份，防止对原始数据造成二次毁坏，后续的数据分析&数据恢复操作将基于镜像文件进行。2、应用工具查看SQL server数据库的底层，发现SQL server数据库底层数据中的头部信息曾经受到毁坏。 3、依据SQL server数据库底层数据分布法则剖析查找被加密的形式。通过剖析发现该数据库页为8K，将底层数据按8K切块并向下查找剖析加密形式，通过剖析发现加密法则：每隔128k进行一次大小为125字节的加密。 4、剖析数据库备份文件底层数据，发现加密法则和数据库局部的加密法则完全相同。 5、SqlServer数据库起始页标记为01 0F，北亚数据恢复工程师在底层检索数据库页的起始标记，发现数据库备份的头部记录完整。通过剖析才晓得数据库备份的头部记录了数据库的备份信息，所以数据库页的起始地位向下偏移，数据库中的加密地位和数据库备份文件中的加密地位刚好错开，因而数据库备份文件中的起始标记未被毁坏。 6、因为数据库加密地位与数据库的备份文件加密地位错开，北亚数据恢复工程师联合数据库备份文件修复数据库中的加密页。 7、数据恢复工程师应用数据库管理工具附加&查看修复好的数据库。通过查看验证，数据库能够失常应用。通过用户亲自对复原的数据进行验证，确认数据库内的所有数据残缺可用，本次数据恢复实现。

服务器故障：服务器中一组由16块硬盘组成的raid6磁盘阵列，其中有一块硬盘因为物理故障掉线，服务器下层虚拟机不可用，局部分区失落。用户重启服务器后发现下层数据还是处于失落状态。 服务器数据恢复过程：1、服务器数据恢复工程师检测故障服务器下层数据，发现是因为有硬盘忽然掉线导致下层虚拟机文件系统被毁坏，能够通过拼接文件碎片的形式复原数据。拼接原理：通过fbb源文件位图信息中的512M位图信息进行拼接。通常状况下，服务器下层的虚拟机损坏的元文件指针类型不同会导致最终指向的数据索引地位也不同。本案例中虚拟机的元文件曾经损坏，通过服务器现有数据是无奈确认指针类型是哪种指向的。如果指针最终指向的地位不是fbb元文件区域，则此办法将无奈复原数据。2、通过逆向验证的办法复原数据：假如下层虚拟机的损坏元文件指针的确指向fbb中的512M位图，依照这一思路间接扫描和拼接服务器底层数据，在拼接过程中同步进行数据验证。3、在拼接数据时发现了两个目录，通过数据验证发现这两个目录十分相似，初步判断其中的一个目录为备份数据。于是北亚数据恢复工程师具体比照了目录一与目录二中的目录、文件和底层数据，发现两个目录中的数据完全一致，确认其中之一为备份数据，因而只需复原这两个目录中的任意一个的数据即可。4、北亚服务器数据恢复工程师对目录一进行拼接后发现文件系统被严重破坏，所有的文件都无奈失常关上和应用，只能对目录二进行拼接和复原。5、服务器数据恢复工程师对目录二中的数据进行了拼接&复原，通过验证发现大部分复原的文件能够失常应用。6、北亚服务器数据恢复工程师持续对不残缺的数据局部进行提取、拼接、手动修复，复原出服务器内的所有的数据。7、经用户亲自对数据进行验证，服务器下层虚拟机能够失常应用，数据残缺，本次数据恢复胜利。 Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

服务器数据恢复环境：某银行服务器，共13块硬盘。 服务器故障&剖析：某公司银行业务忽然解体，无奈失常应用，银行运维人员排查服务器故障，发现服务器有多块硬盘故障离线，下层利用解体，服务器无奈失常工作。因为服务器内的数据非常重要，不仅须要对服务器硬盘进行物理故障修复，还须要复原服务器内的数据。于是运维人员分割咱们数据恢复核心寻求帮忙。因为故障服务器内呈现大量硬盘掉线的状况，北亚数据恢复工程师初步判断是因为服务器磁盘阵列中硬盘掉线数量超过服务器磁盘阵列冗余级别容许的最大数量，导致服务器瘫痪。能够通过修复硬盘物理故障，提取故障盘数据后重组raid的形式复原服务器数据。 服务器数据恢复过程：1、北亚工程师首先对故障服务器进行了初检，发现故障服务器raid磁盘阵列中13块硬盘中的4块硬盘处于离线状态。2、对离线硬盘进行物理故障检测，发现离线硬盘中均存在大量坏道。硬件工程师应用专用设备对坏道硬盘进行了物理修复，对修复好的硬盘做镜像备份。3、对没有发现物理故障的完整硬盘做镜像备份，将所有硬盘数据备份到筹备好的存储池中，以备数据分析和复原应用。4、剖析raid构造并虚构重组raid磁盘阵列，验证重组的磁盘阵列的可用性。如果验证不通过则从新剖析调整重组阵列，直至验证后果失常，数据可用。5、将复原好的数据交付用户亲自验证，没有发现问题。 服务器数据安全Tips：1、服务器产生故障后，切忌对服务器进行操作；也不要随便取出硬盘，免得弄乱盘序。2、如果须要取出硬盘，标记好硬盘的程序之后再取出。3、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏。

服务器数据恢复环境：nas存储服务器，14块硬盘组建raid6磁盘阵列。 服务器故障&剖析：服务器在失常运行过程中忽然有硬盘呈现故障离线，导致磁盘阵列生效，服务器无奈失常拜访了。北亚数据恢复工程师首先对故障服务器内的所有硬盘的底层数据进行了检测，发现服务器的磁盘阵列尽管曾经生效，但thin-lvm构造及thin-lv尚未被毁坏，数据能够复原。thin-lvm算法构造的复杂性决定了复原数据的难度比拟大。 服务器数据恢复过程：1、剖析服务器底层数据获取到重新组建磁盘阵列所必须的信息，利用获取到的信息重组raid6磁盘阵列，还原服务器的原始状态。2、解读lvm配置信息并重组lvm构造，获取与thin-pool相干的meta-lv和data-lv并校验其相关性，通过校验，发现获取到的meta-lv和data-lv是不残缺的。3、剖析meta-lv并获取&解读其中的原信息，获取到残缺的thin-lv信息。通过北亚数据恢复工程师编写的数据提取程序提取所有的thin-lv信息。4、残缺获取到thin-lv信息后，采纳北亚数据恢复工程师编写的程序校验文件零碎的完整性和正确性，没有发现问题。5、解析thin-lv并提取服务器内的所有数据文件。 服务器数据恢复后果：通过北亚服务器数据恢复工程师的剖析和提取，最终残缺提取出了故障服务器内的所有数据，通过工程师测验后由用户验证复原进去的服务器数据的完整性和可用性。通过用户亲自验证，确认本次数据残缺、可用。

服务器数据恢复环境：惠普ML系列某型号塔式服务器，5块SAS硬盘组建raid5磁盘阵列。 服务器故障&剖析：服务器中的一块硬盘掉线，因为磁盘阵列的冗余个性，服务器失常运行，用户没有觉察。直到另外一块硬盘掉线，服务器解体。用户分割咱们要求复原存储在服务器中的设计素材及客户数据。北亚服务器数据恢复工程师检测故障服务器的底层数据，没有发现显著的同步痕迹。 服务器数据恢复过程：1、将故障服务器内的硬盘按编号并贴上标签后取出，检测所有硬盘的物理故障并对所有硬盘中的数据进行镜像备份，备份过程中没有发现显著物理故障。后续的数据分析和数据恢复操作都在镜像文件内进行，防止对原始数据造成二次毁坏。2、剖析服务器内的riad磁盘阵列构造，获取raid相干信息如raid级别、条带大小、条带方向、块大小、硬盘盘序、数据校验形式等。判断故障服务器中硬盘的离线起因。3、依据获取到的raid构造参数组建虚构的磁盘阵列环境，解析虚拟机磁盘及文件系统。4、验证解析的文件系统和文件，确定数据无误后让用户亲自对数据进行验证。确认本次数据恢复后果残缺，正确。 服务器数据恢复Tips：1、正规业余的数据恢复公司检测收费。2、签订窃密协定，防止重要数据外泄。3、数据恢复前将服务器内的数据备份。4、整个复原过程不会对原硬盘有任何的写操作，以确保硬盘数据的完整性。5、服务器阵列瘫痪后应该立刻断电，不要做同步或强制上线操作，避免数据进一步毁坏，应分割业余人员进行复原。

服务器数据恢复环境：北京某公司IBM X系列某型号服务器；服务器上共8块硬盘组建raid5磁盘阵列；服务器上部署有oracle数据库。 服务器故障&剖析：服务器在运行过程中，raid5磁盘阵列中有2块硬盘报警，服务器操作系统启动不了，服务器上部署的ORACLE数据库无奈启动，用户分割咱们数据恢复核心要求复原服务器的数据。RAID5最多只能容许有一块硬盘离线，若有第二块磁盘离线，RAID5磁盘阵列便会解体，不能失常工作。在用户确认之前还没有第二块硬盘离线，所以初步认定RAID卡上的RAID信息可能曾经失落或毁坏。 服务器数据恢复过程：1、对故障服务器中的8块硬盘和未齐全同步的新硬盘进行异或测试，没有发现显著谬误。2、对故障服务器中的全副硬盘进行镜像备份。3、在备份过程中对原始RAID构造进行剖析，北亚数据恢复工程师通过剖析获取到的RAID信息构建虚构RAID环境。对RAID构造进行验证，发现阵列构造无显著谬误，目录构造及文件门路残缺。4、北亚数据恢复工程师批改个别硬盘上的RAID信息，将RAID信息导入到RAID卡并重新启动，阵列能够失常工作。5、退出热备盘进行同步，让RAID回到同步状态。 服务器数据恢复论断：因为异或测试齐全通过，所以该服务器RAID5磁盘阵列故障是因为RAID控制器出错，RAID信息失落引起的。数据恢复实现后，目录构造残缺，ORACLE数据库完整。用户亲自对复原进去的数据进行验证，没有发现问题。

云服务器特点：1、云服务器不须要购买硬件设施，用户依照业务需要领取肯定的费用购买相应的硬软件资源。云服务器提供商的数据中心不仅提供硬件/软件环境，还提供咨询服务。2、云服务器能够充分利用资源，依据业务需要随时调整硬软件资源，防止老旧设施的淘汰和购买新设施/部署软件的所消耗的工夫和老本。3、云服务器提供商有业余的技术人员对服务器进行保护，节约服务器的搭建保护老本，能够让用户将更多资源投入到本身的外围业务中。 **云服务器数据恢复案例： 云服务器数据恢复环境：某云ECS网站服务器，linux操作系统，mysql数据库。 云服务器故障状况：在执行mysql数据库版本更新测试时，将本应在测试库执行的sql脚本谬误地在生产库中执行，局部表被truncate，局部表内的大量数据被delete。该实例内数据表均采纳innodb作为默认存储引擎。 云服务器数据恢复流程：1、因为用户的ECS内有其余业务在运行，为保障被truncate表的底层数据不被毁坏，北亚数据恢复工程师首先将mysql的data目录所在分区备份。2、因为用户须要复原的12个表内不存在大字段类型值和myisam引擎表，为节约数据传输工夫，北亚数据恢复工程师利用工具扫描数据段并下载获取复原数据所必须的数据库段碎片。应用innodb引擎的mysql数据库复原数据必须依赖表构造信息，mysql的表构造信息存储于对应表名的.frm文件内。本案例中.frm文件完整可间接应用。下载须要复原的表对应的.frm文件。3、剖析零碎表，读取数据段内的零碎表信息，获取须要复原的12个表在零碎表内的注册信息。4、在下载实现的数据段文件内提取对应于各表的数据页，解析对应表的.frm文件获取到该表的表构造信息,通过表构造信息获取到底层数据调配规定，依照规定拆分数据段内二进制数据并对不同类型数据进行字符展现转换（各类整形、浮点型、工夫型等），实现数据段到sql语句的转换。5、复原被delete数据的表，根本流程和复原truncate表的流程相似，不同点在于数据解析时须要提取被标注为“delete”的记录。6、依据解析出的表构造信息在复原环境中的mysql实例中创立表，并将复原出的数据导入。7、因为间接从底层抓取出的记录可能存在主键不惟一（引擎在存储时产生的长期记录）和记录反复（缓冲段）以及乱码（扫描数据段时呈现特征值匹配胜利但不属于该表的数据段）等状况，北亚数据恢复工程师对提取出的记录异样进行人工解决。8、数据验证。开启远程桌面，由用户亲自验证看数据是否正确、数据量是否失常。通过用户验证，truncate表和delete记录的表都残缺复原。

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

Linux误删除及误格式化的数据恢复计划针对的文件系统：1 、基于EXT2/EXT3/EXT4文件系统 ；2 、基于Reiserfs文件系统；3 、基于Xfs文件系统。 Linux误删除及误格式化的数据恢复解决方案：一、故障检测：1、检测是否存在硬件故障，如有硬件故障先解决硬件问题 。2、以只读形式检测故障体现是否与用户的形容雷同。 二、数据恢复：1、备份：以只读形式对故障磁盘做残缺镜像。2、如果须要复原残缺目录构造，则先须要残缺复原已失落文件节点，再复原数据；如果节点无奈复原，则按文件类型进行复原。 3、复原后的数据会暂存在另一个存储体上。 三、验收：对复原好的数据进行验证，确认其正确性和完整性。 Linux误删除及误格式化后复原数据的可能性：1、针对EXT2/EXT3/EXT4的数据误删除：在EXT2文件系统上误删除数据个别会保留相应的INODE，只有删除后没有笼罩，通常能够将数据连同目录、名称残缺的复原进去。在EXT3/EXT4上误删除数据不会保留INODE中的索引信息，无奈复原目录及文件名称，只能按文件类型进行复原。如果文件数量少或者文件类别规律性强，可通过局部日志或文件外部规定进行复原。例如mysql、oracle数据库文件删除后如果没有笼罩通常可残缺复原。如删除之后有数据写入，则须要看具体情况：写入越多，复原概率越低；写入越少，复原概率越高。2、针对EXT2/EXT3/EXT4的误格式化：EXT2/EXT3/EXT4误格式化后，如果格式化后的文件系统与格式化之前的文件系统构造雷同，则之前文件系统的节点区将全副被笼罩，只能按文件类型进行复原。3、针对Reiserfs的数据误删除/误格式化：数据删除或格式化后如无新的数据写入，通常能够100%复原；如删除或格式化之后有数据写入，则须要看具体情况：写入越多，可复原概率越低，写入越少，可复原概率越高。4、针对Xfs的数据误删除/误格式化：数据删除或格式化后如无新的数据写入，通常能够100%复原。如删除或格式化之后有数据写入，则须要看具体情况：写入越多，可复原概率越低，写入越少，可复原概率越高。 数据恢复工夫：影响数据恢复的工夫有多方面的因素。通常状况下，在北亚数据恢复核心复原Linux误删除/误格式化的数据约须要2-3天；如果有非凡或者简单状况，须要视状况而定。 数据安全小贴士 ：1、任何类型的存储设备都没有100%的平安保障，对于重要数据咱们须要常常去备份，能够应用一些数据同步工具进行数据备份。 2、呈现数据劫难时，最好不要再有任何操作。如有条件，将硬盘或其余存储介质进行残缺镜像。 3、数据删除后，即便不写入数据，单纯的读取也容易毁坏文件系统日志。所以在误删除/误格式化数据后，应尽快umount文件系统。

服务器数据恢复环境：一台HP EVA某型号存储设备；共23块硬盘，下层映射给一台windows零碎服务器。 服务器故障状况：存储设备有三块硬盘的指示灯变黄色，存储设备还在失常运行。管理员在更换亮黄灯的故障硬盘过程中，存储设备中又有一块硬盘的批示变黄离线，这时存储设备曾经不可用了。 服务器数据恢复过程：1、把故障存储所有磁盘以只读的形式挂载到一台筹备好的备份服务器上，将所有磁盘都镜像成文件。后续的数据恢复操作都基于镜像文件上进行，防止对原始数据造成二次毁坏。2、在镜像备份的过程中，北亚数据恢复工程师发现这4块故障硬盘都存在物理故障-盘片损坏，数据无奈备份。因为4块故障硬盘齐全损坏无奈应用，只能利用剩下的19块硬盘来进行复原。因为之前3块硬盘离线的时候，存储设备还能失常应用，当第4块硬盘离线之后存储就解体了。因而在缺失一块硬盘的状况下复原进去的数据肯定是不全的。3、通过头部信息解析根本信息，如下图：4、解析RSS组信息，如下图：5、解析lun信息，解析lun之后就寻址位图信息进行数据的解析，如下图：6、通过lun信息提取MAP位图信息，通过MAP位图信息提取数据块组合成逻辑卷并进行解析，如下图： 服务器数据恢复论断：因为多块硬盘故障离线导致存储设备不能失常拜访，离线硬盘盘片划伤，无奈复原离线硬盘的数据。因为咱们数据恢复工程师团队对EVA存储底层构造有过深刻的钻研，并且有解决过多例相似故障的教训，所以整个复原过程比较顺利。复原进去的数据经用户亲自验证没有发现问题。

【案例一】一块西数移动硬盘不小心摔了，插到电脑上就不认盘，之后没在其余的任何操作。这是比拟典型的硬盘故障类型：故障起因就是移动硬盘磁头损坏。北亚数据恢复工程师在用户批准的前提下收盘，对移动硬盘收盘换磁头。，因为后期正确的措施（摔过的硬盘不要再加电尝试读取）和北亚数据恢复工程师的精确判断，胜利帮用户复原了移动硬盘外面的招标标书和其它重要数据，用户XX团体刘总万般感激。用户刘总XX团体后续和北亚数据恢复核心签订了数据安全外包协定。 XX团体刘总的移动硬盘 【案例二】某政法大学王同学一块希捷的移动硬盘，保留大学3年的所有材料和集体写的一些无关守业的文件。王同学某天把移动硬盘通过数据线插到到笔记本上后发现前两天还失常应用的硬盘无奈辨认了，更换数据线甚至更换电脑，移动硬盘还是无奈辨认。王同学把移动硬盘拿到北亚数据恢复核心，通过北亚数据恢复工程师检测发现是硬盘固件问题导致的故障。北亚数据恢复工程师通过PC3000设施修复了固件问题，然而又发现移动硬盘存在大量坏道。尽管硬盘能够辨认，但有些数据还是无法访问或拜访拷贝报错，北亚数据恢复工程师又将移动硬盘通过PC3000的DE做了一个残缺的镜像，将王同学保留了几年的文件资料完整复原进去了。 某政法大学王同学的移动硬盘 移动硬盘常见故障状况和解决办法： 1、硬盘自身没有问题，数据线、硬盘盒或接口卡问题。这类的状况很常见，因为买到了翻新、返修或造假的移动硬盘，数据线、硬盘盒和接口卡可能不是原装的，品质无奈保障，应用一段时间后坏掉可能性很大。这种故障导致移动硬盘时认时不认，到起初就齐全不认了。解决这类问题的办法很简略：间接换线、换盒子和接口卡，硬盘就能够失常应用了。 2、硬盘品质问题，固件损坏或呈现坏道。新盘应用多年也会呈现这类问题，翻新、返修盘应用一段时间也容易出这类问题。归根结底就是硬盘的品质问题。其中硬盘呈现坏道是最常见的问题之一，其实新盘在出厂的时候也是有坏道的，只不过是做了暗藏，当硬盘固件出问题的时候，坏道就被释放出来，导致硬盘无奈工作或拜访迟缓。呈现这类问题的解决办法：如果没有重要数据就间接更换新盘，如果有重要数据就只能求助于正规业余的数据恢复公司。 3、人为导致移动硬盘无奈工作或损坏。这类的问题个别都是用户误操作（移动硬盘搁置在湿润/低温等非凡环境、插到一些未知平安的设施上、带电低空坠落等），导致硬盘电路板芯片烧毁、磁头或电机损坏、盘片划伤等。解决这类的问题须要业余的设施和技术，倡议没有业余设施和数据恢复技术的用户不要轻易尝试，如果移动硬盘有重要数据，就间接找正规业余的数据恢复公司帮忙解决。

常常应用电脑和移动硬盘的用户，如果察觉到电脑运行速度变得很慢，即便做了磁盘整顿和系统重装操作后速度还是没有复原到失常状态，这个时候就要小心是硬盘盘片呈现坏道了。 如果这个时候用硬盘检测软件扫描硬盘就会发现扫描界面上呈现很多绿块，也有可能呈现褐色或红色的色块，这就表明硬盘曾经或行将呈现坏道，那么什么是硬盘坏道？ 百度百科给出的定义：硬盘应用久了就可能呈现各种各样的问题，而硬盘“坏道”便是这其中最常见的问题。硬盘呈现坏道除了硬盘自身品质以及老化的起因外，次要是平时在应用上不能善待硬盘，比方内存太少以至应用软件对硬盘频繁拜访，对硬盘过分频繁地整顿碎片，不适当的超频，电源品质不好，温度过高，防尘不良，触动，强制关机等。硬盘呈现坏道除了硬盘自身品质以及老化的起因外，有很大水平上是因为平时使用不当造成的。硬盘坏道依据其性质能够分为逻辑坏道和物理坏道两种：逻辑坏道是因为一些软件或者使用不当造成的，这种坏道能够应用软件修复；而物理坏道则是硬盘盘片自身的磁介质呈现问题，例如盘片有物理伤害，这类故障通常应用软件也无奈修复。所以无论是逻辑坏道还是物理坏道都会导致电脑或移动硬盘应用不失常，重大时导致硬盘不辨认，数据无奈读取，如果电脑或移动硬盘呈现坏道了该怎么办？ 硬盘检测出坏道 北亚数据恢复核心集体业务部门简直每天都会接到因为坏道导致的数据失落或硬盘读不进去的征询，用户提到的故障体现基本上就是：“硬盘提醒要格式化”、“不能拜访某个文件或者文件夹了”、“昨天还用的很好，没失常退出间接拔了一次，第二天移动硬盘就无奈辨认了”等。这些故障体现其实就是固件损坏或呈现坏道了。如果硬盘里没有重要的数据文件，就倡议换硬盘了；如果硬盘里有重要的数据就须要到正规业余的数据恢复公司做数据恢复了。硬盘的坏道和固件问题是无奈通过在网上找几个所谓的数据恢复软件就能解决问题的，须要价格昂贵的业余设施来复原数据，比方ACE公司的PC3000和MRT实验室公司的MRT设施。为什么硬盘会呈现坏道？其实硬盘在出厂的时候就曾经有坏道，只不过被写入了固件中的P表和G表里，所以用户在应用的时候或用软件测试的时候感觉不到有坏道，但当固件模块损坏或盘片呈现磁性弱化，坏道就会被开释，硬盘就不能失常工作了，呈现相似如下的报错： 有坏道的硬盘读取文件时的报错 硬盘呈现坏道问题的几种解决方案： 一、大量坏道：如果发现电脑或移动硬盘拷贝文件速度显著变慢或者偶然报错。这个时候就须要连忙去备份重要文件并及时更换硬盘，不要等到硬盘无奈辨认或文件彻底无奈关上才想到去备份数据或换硬盘。 二、硬盘不辨认或拷贝数据显著变慢的：如果呈现这些景象，问题就曾经比较严重了。如果硬盘外面没有重要数据就间接换新盘，如果有重要的数据，就尽量少加电尝试，尽快找正规业余的数据恢复公司解决。如果坏道不重大，有很高的概率复原全副或者绝大部分数据，如果呈现大量的坏道，可能数据就不敢保障残缺度了，复原50%的可能性也很大的。 三、硬盘呈现异响，时认时不认：呈现这类故障少数状况下是因为硬盘应用年限过长，磁头组件老化、轻微的摔磕碰撞等，如果这类问题重大到磁头损坏，盘片划伤，数据也就无奈复原了。 北亚数据恢复工程师提醒您：坏道是硬盘最常见的故障之一，并不可怕，但用户的一些不当操作会对硬盘造成二次毁坏，也有可能是致命的毁坏，这时不仅硬盘不能应用，数据也无奈复原。所以一旦呈现上述问题请找正规业余的数据恢复公司征询，保证数据不会被二次毁坏，造成无法弥补的遗憾和损失。

服务器数据恢复环境：MYSQL数据库服务器，2块硬盘组建RAID1；DATA卷存储了200多个数据库；每天将每个数据库dump出后间接压缩成.gz包，而后将所有重要数据库的.gz 包放在一起压缩成一个总的.tar.gz包，笼罩原来的备份；数据文件及备份文件全副存储于DATA卷上。 服务器故障&剖析：在一次惯例的保护中，管理员不小心将DATA卷下的所有文件全副rm，删除后管理员马上关闭系统，再未做其它操作，但在删除那一刻有大量终端在拜访此服务器。管理员分割咱们数据恢复核心要求复原mysql数据库文件（如myd、frm、myi(可重建)文件），或者每个数据库的.gz包，或者所有重要数据库总的.tar.gz备份包。 实践上，在ext3文件系统下删除数据会革除inode中除节点类型、日期外的其余属性如文件大小、数据存储地址等，这些属性会全副清0。同时目录表中会以目录条目长度的形式屏蔽掉已删除的文件，但会保留节点编号，最初会扭转BITMAP中的空间占用标记。即便是目录表中存在删除文件的节点编号，但因节点内容曾经没有须要的货色，与数据区也是脱钩的。从数据角度来说，大多数文件类型都会有特定的文件头标记，通过文件头标记是有可能找到删除文件的起始地位的。但EXT3文件系统以块组为单位进行存储，同时数据与索引是混合存储于数据区的，所以数据间断存储的可能性十分小，所以依照文件格式进行解决可行性不大。惟一的计划是联合上述几个特色，加上对日志和存储过程的模仿剖析，尽可能地还原实在的存储构造。 服务器数据恢复过程：1、首先对故障服务器的所有硬盘做残缺镜像备份。2、基于镜像文件对总的.tar.gz进行剖析并尝试复原，但复原进去的文件解压到一半左右就报错，后续文件列表也无奈列出。通过数据恢复工程师的剖析，发现呈现这种状况是因为在删除DATA卷下的所有文件时仍有数据写入毁坏了文件。3、对每个数据库的.gz包进行剖析并尝试复原，大多数数据库的.gz包复原胜利。4、对于未复原胜利的数据库.gz包，间接复原其myd\frm数据文件，最终将所有数据库的.gz包复原胜利。5、通过用户亲自验证，复原进去的数据残缺可用。 服务器数据安全Tips：１、LINUX EXT3文件系统下数据删除后应尽快断掉文件系统I/O，通常umount文件系统即可。２、对故障卷做dd备份，确保数据恢复操作不会对原始数据进行二次毁坏。

服务器数据恢复环境：某网站服务器，无品牌组装机器；4块SCSI硬盘组建RAID0；LINUX操作系统，存储的MYSQL数据库、网站程序和网页文件。 服务器故障&剖析：服务器电源损坏，用户找到一家电源销售商更换电源。可能是胆怯损坏硬盘中的数据，电源销售商居然把硬盘全副拔掉（只留下RAID卡）启动服务器进行测试，实现测试后再次连贯硬盘启动服务器，发现RAID信息曾经毁坏。之后又做了一些操作（未知）。咱们核心拿到故障服务器时的故障体现：启动操作系统时提醒有效的疏导记录。用户要求复原服务器中的数据，同时从新激活修复服务器的操作系统。拔掉全副硬盘保留RAID卡进行开机测试，服务器在加电检测RAID控制器时会认为所有硬盘都呈现故障，从而导致RAID逻辑卷下线。连贯好所有硬盘从新加电后，尽管所有硬盘是完整的，但RAID控制器为了平安思考，不会从新加载所有硬盘，重建RAID卷。这时候如果及时采取正确的操作还有可能复原数据，但预计用户过后进行了谬误的操作如重建，从而导致所有数据不可用。RAID0自身不会波及到同步操作，除非重建时清0数据，其余操作不会对数据造成致命性的毁坏，但须要剖析原RAID的构造，并进行虚构重组。 服务器数据恢复过程：1、按单盘形式把故障服务器中所有硬盘进行残缺的镜像备份。2、在镜像中剖析原RAID的构造参数。3、依据获取到的原RAID构造参数搭建虚构RAID环境，组建RAID逻辑卷。4、为保障数据完整性，将数据打包为TAR.GZ。5、重新配置RAID，装置零碎，将复原后的数据迁徙回原零碎。6、由用户亲自对复原进去的数据进行检测，确认复原进去的数据残缺无效。

本文所提到的计划/办法实用于：1、ext2 ext3 reiserfs xfs等文件系统；2、提醒文件系统须要FSCK时，未执行FSCK或实现执行FSCK。 LINUX零碎执行FSCK出错的故障体现：1、无奈挂载分区;2、文件/目录失落，根目录下生成/LOST+FOUND文件夹，外面有大量#XXXXXX类的文件和目录;3、FSCK很快报错实现；4、执行FSCK时有大量提醒如批改节点、清0节点等操作。 LINUX零碎须要执行FSCK的解决计划：1、如果碰到零碎提醒FSCK时，切记不要自觉操作。如有可能请尽快断开零碎，UMOUNT所有分区。2、确定必须执行FSCK时，可先做以下筹备工作：一：可当时用dd命令将所波及到的分区输入到另外的存储体上（最好不要在出错的存储体自身上做dd） 命令如下（按具体情况进行批改）： dd if=/dev/sda0 of=/dev/sdb0 .....二：将整个LINUX存储体挂载到虚拟机环境，将LINUX存储体设为Nonpersisten模式后再执行FSCK。执行FSCK后如果数据完整，应尽快通过FTP等形式拷贝进去。三：将整个LINUX存储体挂载到其余零碎上（如WINDOWS），做好镜像后再做FSCK。如以上工作都因客观原因无奈施行，然而又不得不执行FSCK的时候，那就只能在过程中小心察看FSCK的执行提醒（关掉-a）。如果呈现提醒如节点谬误需更正或清0、节点形容文件大小不正确等信息，应该立即进行执行FSCK。3、因为这类故障产生后进行数据恢复须要参考很多信息，所以呈现这类故障后应该尽可能让服务器操作系统处于不工作状态，至多不能再次MOUNT分区。4、寻求业余正规的数据恢复公司帮忙。 硬盘镜像的计划：1、可用雷同或大于源盘容量的硬盘作为指标盘，将源盘全副以扇区的形式CLONE到指标盘。2、可将源盘齐全以扇区形式输入文件到某大容量存储空间（如大容量硬盘、NAS、SAN、DAS等）。

数据库数据恢复环境：LINUX EXT3文件系统，部署ORACLE数据库。 数据库故障&剖析：管理员在建设测试库时选错了服务器，在ORACLE数据库平台上CREATE了一套新库，创立至10%左右时发现异常，停止操作。查看数据库目录发现只剩下SYSTEM2.DBF这一个库，其余的库（次要为SYSTEM1.DBF）失落。通过北亚数据恢复工程师团队通过会诊，最终确定了计划：间接重建原先文件的属性节点，即次要复原原文件的大小、存储地位等信息。通过节点从新形容文件。如果上述办法不可行，能够依照ORACLE数据库的页面结构特征进行剖析与复原。 数据库数据恢复过程：1、对故障数据库所波及到的硬盘做镜像备份，后续的数据恢复操作在镜像备份文件上进行，防止对原始数据造成二次毁坏。2、通过北亚自主开发的针对LINUX EXT3文件系统误删除的复原软件，咱们找到了一些ORACLE数据库文件，导出后发现导出的SYSTEM1尽管构造完整，但文件大小与用户形容的文件大小相差很远。3、通过仔细分析，确认导出的SYSTEM1.DBF为用户创立测试库时生成的库，因未全副生成便被勾销，所以只占用了很小的初始化空间，与原数据库无关。4、从新对全盘进行扫描，联合ORACLE自身的构造，锁定原SYSTEM1.DBF的数据区，但发现这块数据区曾经被新生成的几个新库笼罩了。5、通过北亚数据恢复工程师的致力，将用户形容大小的失落的数据胜利导出。但通过验证后发现，导出的数据尽管构造完整、无损坏，但因头部库构造及字典均蒙受毁坏，无奈重现，只能在数据完整的区域内再次查找数据。6、ORACLE工程师通过对两头数据进行剖析、重组，从新导入到新库中并进行验证，最终用户确认所须要的数据曾经全副复原。

服务器数据恢复环境：北京某科技大学，某品牌PowerEdge系列某型号服务器，6块SAS硬盘组成RAID5；操作系统REDHAT，文件系统EXT3，分区采纳LVM形式，存储着该大学某研究室运算1年多的重要数据。 服务器故障&剖析：未知起因导致服务器解体。管理员进入RAID管制界面查看发现1号盘与6号盘状态显示损坏。征询服务器原厂工程师后，管理员强制上线6号盘，后果raid无奈启动（操作系统也装置于此RAID）。管理员意识到问题严重性，马上进行所有操作。依据用户的形容及故障体现，北亚服务器数据恢复工程师推断本案例中的RAID5阵列中应该有一块硬盘早离线，这时候磁盘阵列还能失常工作，起初又有一块硬盘离线，从而导致RAID阵列解体。依照管理员的形容，6号盘早离线，1号盘后离线。如果下面的推断属实，1号盘只有能失常读取即可复原全副的数据。但管理员强制上线6号盘，可能会导致文件系统不统一，引起其余盘的数据产生变更。通过钻研，北亚数据恢复工程师敲定了复原数据的思路：首先检测所有硬盘状态，剖析RAID信息，剔除掉古老数据盘。依据剖析进去的RAID信息重组RAID，读取数据；或间接以EXT3的模式复原数据。 服务器数据恢复过程：    1、服务器数据恢复工程师拿到故障服务器硬盘后以只读形式对所有硬盘做镜像备份，应用不含RAID性能的SAS适配器作为物理连贯进行备份。后续数据恢复操作都在备份文件上进行，防止对数据造成二次挫伤。2、基于镜像文件对RAID构造进行剖析，获取到原始RAID相干信息。3、对RAID进行一致性校验，后果发现大量的不匹配。4、从6块盘中剔除掉古老盘。但此时发现前局部区构造的内容谬误，应该为强制上线6号盘所导致的问题。5、修改硬盘构造，将LVM改为一般分区指引。6、通过北亚自主研发软件解释EXT3并读取数据，以SAMBA形式导出至LINUX EXT3指标分区。到此步数据恢复曾经实现。7、通过用户亲自检测没有发现问题，帮助用户把数据导入筹备好的环境中，一切正常。

数据库复原环境：联通海南分部信息平台，HP-UX小型机；ORACLE数据库，卷文件系统为VxFS。 数据库故障&剖析：工程师误RM掉了重要ORACLE数据库，失落了所有的数据表、UNDO、LOG等。通过北亚数据库数据恢复工程师团队会诊，给用户方提供两套oracle数据库复原计划：计划一：剖析文件系统规律性，对特定文件的节点进行重建。重现原来文件属性（名称、地位、大小等）。计划二：依据ORACLE数据库自身构造个性，对全盘进行规律性剖析&总结，复原所有ORACLE数据表、LOG及UNDO文件。因ORACLE数据库表头会形容表在ORACLE环境中的名称及大小，故表名称问题亦可解决。 数据库数据恢复过程：1、 数据恢复工程师近程登录到HP-UX零碎，对故障卷执行DD操作，输入到另外卷上。2、 通过FTP传输到WINDOWS平台，将目标盘快递到咱们数据恢复核心。3、 实施方案一，利用北亚自主研发数据恢复软件胜利剖析出除UNDO1外的所有其余文件节点表，依据节点将文件全副提取进去。4、 实施方案二，胜利复原出所有文件，排除UNDO1后与计划一比拟，后果2这套计划复原进去的数据1个字节都不差。基于这个后果咱们能够判断：除UNDO1外，其余文件都是正确的。5、 因UNDO1并不影响数据，且按计划一论断看也应该正确，到此步曾经实现数据恢复。6、 帮助用户将所有复原进去的数据库数据还原到筹备好的HP-UX零碎，胜利启动服务，数据完整无缺。 数据安全Tips：UNIX及LINUX误删除后应尽快UMOUNT掉卷，最好间接关掉设施，DD之后再做其余操作。

服务器数据恢复环境：某网站服务器，LINUX操作系统；6块硬盘组建RAID5；逻辑磁盘中只蕴含一个卷，文件系统为EXT3，寄存所有客户的数码照片。 服务器故障&剖析：网站失常工作中卷忽然离线，管理员查看服务器发现1号与4号两块硬盘指示灯显示黄色。致电服务器厂商售后，厂商技术人员提供的解决方案为随机抉择一块报警的硬盘强制上线。管理员抉择4号盘强制上线，上线后可MOUNT，但很多目录打不开，某些目录下近几天的文件失落。用户意识到问题的严重性后马上关机，没有做其余任何操作，分割咱们数据恢复核心寻求帮忙。通过数据恢复工程师检测，发现1号与4号盘并非同时OFFLINE，4号盘先离线，之后1号盘离线从而导致整个RAID解体。管理员进行强制上线操作后，因数据不同步呈现了目录打不开或文件失落等故障景象。MOUNT胜利零碎便会写入一定量的数据，写入数据的条带中的测验信息会从新生成，导致局部测验信息古老。这种状况下是无奈通过还原RAID构造的形式复原数据，只能依附提取数据的形式进行复原。 服务器数据恢复过程：1、  剖析原始RAID5的构造（RAID信息），去掉4号盘，退出1号盘，虚构搭建RAID。2、  通过北亚自主研发软件提取虚构逻辑卷数据，发现1号盘有不法则的坏道。3、  利用业余工具将1号盘残缺镜像，胜利读取90%以上的坏道。4、  将镜像退出到虚构RAID中再次提取数据。而后将数据输入到另外筹备好的硬盘上。5、  通过用户亲自检测，确认复原99%以上数据。 RAID数据安全Tips：1、在两块以上盘离线的状况下，应该通过查问日志等形式确定硬盘离线的先后顺序，即便强制上线（尽量少做这类操作），也须要做到危险最小。2、能够通过减少DRAC或hotspare等形式缩小此类事变的产生概率。3、如果数据重要，呈现此类问题后最好后行征询业余的数据恢复公司后再进行下一步操作。

服务器数据恢复环境：新网企业邮件服务器；组建RAID5，文件系统为REISERFS；一个数据分区，寄存上百万企业用户的邮件。 服务器故障&剖析：服务器在失常运行过程中，RAID忽然OFFLINE。管理员查看发现故障服务器有两块盘报警，将其中一块盘强制上线后却发现卷无奈挂载，于是执行FSCK并REBULD TREE，实现上述操作后卷依然无奈挂载。征询多家数据恢复服务商均无奈提供可行的解决方案，最终新网抉择咱们数据恢复核心进行数据恢复。这种RAID故障在咱们数据恢复核心接到的cases中是很常见的。因为报警的两块盘并不是同时掉线，如果强制上线先离线的硬盘会导致数据区的新旧数据混在一起，文件系统构造不统一。强制上线会在读写过程中生成新的测验条带，会影响一部分数据。如果读写不多或根本无法MOUNT，状况的严重性会小很多。本案例中最重大的问题在于REBUILD TREE，此操作相当于将一个混淆的文件系统间断化，后果会导致文件系统的所有构造体全面出错，这种状况通常是无法挽救的。加上用户的文件目录构造非常复杂，文件总数粗略预计上亿，复原数据的机会很小。 服务器数据恢复过程：    1、首先对故障服务器所有硬盘做镜像备份，后续的数据恢复操作都在备份文件上进行，防止对数据二次毁坏。2、服务器数据恢复工程师先试图将文件系统构造区独自提出来进行剖析，但REISERFS文件系统区绝对扩散且无规律，通过北亚自主研发的程序对文件系统构造区进行提取和剖析。在本案例中，仅1级节点提取进去的数据就有好几个G，可见本案例文件构造的简单。3、对文件系统区进行一致性测验，修改谬误中央。本案例中好多文件系统节点区都因测验关系，使要害属性字节产生了扭转。通过北亚自主研发的程序将所有节点状态对立初始化，对节点进行一致性解决。4、实现上述两步操作后有2种计划复原最终的数据：第一种计划：在LINUX零碎下再次执行FSCK，后果施行这种计划后发现成果不好，起因是LINUX FSCK的性能无限，如果在父节点稍有谬误，其子节点便会被全副打入到LOST+FOUND里，无奈还原本来的目录构造。第二种计划：通过只读形式，在WINDOWS环境下用北亚自主研发的程序提取数据。在具体的施行过程中，须要一直批改程序并疏忽一些谬误，最终提取出数据。5、由用户对复原进去的数据进行检测，确认须要的数据根本都复原进去，能够失常读取。 服务器数据恢复总结：RAID5磁盘阵列两块硬盘先后离线，然而又不晓得离线先后顺序的case很多。碰到这种状况须要咱们审慎解决。如果能够查问到日志，通过日志确定为好。如果强制上线出错，应马上进行操作，切不可做FSCK等操作。LINUX的FSCK操作危险很大，做之前肯定要看清楚提醒，如果出错信息异样，应抉择其余计划。

服务器数据恢复环境：某医院存储服务器，存储了十几年的CT照片等文件的备份；8块硬盘中的7块硬盘作为数据盘组建RAID5，1块作为热备盘。 服务器故障：医院方发现存储服务器中的数据不失常，找过多家数据恢复服务商对故障服务器做过复原操作，具体操作不详。 服务器数据恢复过程：1、咱们数据恢复核心接手这个case后，首先对故障服务器中所有硬盘做镜像备份。2、基于镜像文件做检测剖析，所有盘均通过异或测试，获取到7块数据盘的盘序、块大小、校验形式及热备盘。3、通过检测发现7块数据盘组建的近2TB的数据只有一个区，而且这个分区刚刚被格式化过。据此能够推断：要么故障服务器中的RAID5被强制上线后格式化；要么就是原始RAID5没有损坏，只是被格式化过。4、文件系统被格式化为NTFS，逻辑卷前几个G的空间内肯定存在大量用户FILE RECORD，如果能够找到这些文件，应该就能够复原文件。5、尝试在逻辑卷前几个G的空间内寻找用户FILE RECORD，后果满载而归。呈现这种状况有两种可能：一是被从新初始化后再格式化；二是$MFT不在分区后面或者数据分区地位很靠后。6、试图在其中一块盘中查找所有可知的FILE RECORD，在50%左右的空间区域内发现大量的FILE RECORD。通过剖析后居然发现原来的盘序、块大小及热备盘和之前剖析的后果都不雷同，盘序更是相差很多。7、返回每块盘后面物理地址进行察看，发现所有盘前2G的数据简直都为0。联合后面所有的剖析后果，北亚数据恢复工程师最终断定了用户的操作：RAID产生异样后，用户将局部硬盘取出但未标记盘号，从新插回硬盘后开始初始化。当硬盘开始写操作后发现状况不对，马上对服务器进行了关机操作，重启服务器后发现RAID仿佛又失常了。进入零碎后发现逻辑卷空了，于是又对其进行了格式化。8、从新剖析RAID信息，因分区太大无奈重组，北亚数据恢复工程师只能手工批改局部数据并导出，最终复原出50%左右的数据。其余数据因FILE RECORD失落无奈找到名称与目录，对医院而言，即便复原出这些无奈找到名称与目录的数据也没有意义。

服务器数据恢复环境：POWEREDGE系列某型号服务器；LINUX零碎+RAID5。 服务器故障：管理员执行FSCK操作后LINUX零碎无奈MOUNT。 服务器数据恢复过程：1、通过北亚数据恢复工程师检测，发现RAID5阵列没有问题。然而执行FSCK操作后超级块落第1个块组中的位图、形容和根目录均被垃圾日志填充，无奈间接获取到文件系统的所有信息。2、依据现存的文件系统节点及残留的日志区，还原出原来的超级块。3、通过剖析还原进去的SUPERBLOCK，咱们得悉文件系统为EXT3，原日志节点为8。4、依据磁盘构造剖析出日志节点的起始地位失去其大小，而后反过来剖析其INODE，失去根目录节点。5、根目录区域中有500多个LBA已被垃圾日志填充，北亚数据恢复工程师从日志中还原根目录记录，还原其余第一个块组内可能的INODE，而后结构化文件系统。6、这个时候曾经能够在LINUX下进行MOUNT了，少数数据曾经能够读取。但很多用户须要的数据出错，狐疑是在应用当中解体造成的。7、依照EXT3的特点进行索引跟入，后果发现少数不可读节点被日志垃圾填充。8、北亚数据恢复工程师对日志文件进行剖析。如果能够回溯，则间接生成好节点；如果日志无参考，则通过数据区构造进行剖析。（本案例中所有目录区均完整）9、实现上述操作后，用户须要的数据都残缺复原进去，本次数据恢复实现。

服务器存储设备数据恢复环境：EMC某型号中端存储设备，反对block，file和vvol三种服务类型；存储设备连贯了2台硬盘柜，2台硬盘柜下面有2组相互独立的POOL，共21块520字节的硬盘。 服务器存储设备故障：工作人员的误操作将2组POOL上的局部数据卷给删除了，一共有5个数据卷被删除。于是分割咱们数据恢复核心进行数据恢复。咱们拿到故障存储设备的所有硬盘后先对所有硬盘进行镜像备份，并将硬盘转换为512字节的格局。 服务器存储设备数据恢复过程：1、基于镜像文件对误删除波及到的硬盘数据进行底层剖析，发现一共配置了2组RAID6：其中一组RAID6由11块成员盘组成，另外一组RAID6由10块成员盘组成。依据剖析获取到的RAID信息虚构重组出2组RAID6，并别离导出成镜像文件。 2、读取，整顿每组RAID6后面的全局位图信息。全局位图如下图： 将整顿好的位图信息写入数据库。全局位图中的offset代表RAID（POOL）中的数据块的块号，依据块号能够大抵获取到RAID（POOL）中被删除的数据卷对应的已开释的数据块。 3、扫描获取到的自在数据块，找到被删除的数据卷的头部。确定用户数据的一个索引信息，依据这个索引信息索引到残缺的用户数据卷。读取删除的数据卷的头部，获取到用户数据卷的局部索引位图。持续遍历扫描自在数据块获取残余的索引位图。 4、用户删除的5个数据卷全副为NTFS格局。依据自在数据块位图和用户数据卷索引位图，联合NTFS文件系统的构造，北亚数据恢复工程师编写程序对自在数据块进行匹配拼接，最终残缺拼接还原出5个NTFS格局的数据卷。 5、数据卷拼接实现后校验数据卷中NTFS文件系统的正确性及完整性并修复文件系统中的谬误。对于局部未匹配到的自在数据块，北亚数据恢复工程师通过手工进行剖析解决并拼接到相应的数据卷中。 6、解析复原进去的数据卷，将数据拷贝到用户筹备好的空间中。 数据恢复后果：通过用户的亲自验证，被删除5个数据卷的数据基本上完全恢复并且全副可用。通过课题攻关，北亚数据恢复工程师团队胜利逆向解析出EMC存储的数据算法构造，EMC存储数据卷删除、硬盘损坏、控制器故障等导致数据失落的问题能够交给咱们来解决。

数据库数据恢复环境&故障：数据库环境：Sybase版本-SQL Anywhere 8.0 数据库故障：数据库无奈启动。谬误提醒如图： 而后应用Sybase Central连贯后报错，如下图： 通过和用户沟通以及对故障Sybase数据库的剖析。北亚数据恢复工程师最初得出的论断是：忽然断电造成Sybase数据库无奈回写失常数据，导致多个存储页数据不统一，零碎表形容和存储表不统一，并有一些存储页底层数据齐全芜杂。 数据库数据恢复过程：1、在Sybase数据库底层北亚数据恢复工程师修改芜杂和谬误的存储页，并对系统表局部信息进行更改。2、Sybase数据库修复工作实现后，启动Sybase数据库胜利。3、应用Sybase Central胜利连贯Sybase数据库，经用户亲自验证没有发现任何问题。 总结：Syabse数据库利用和自身架构绝对比较复杂，很多公司的技术人员对Sybase数据库底层构造和运行机制也不相熟，这些状况对Sybase数据库的数据恢复和修复造成很多艰难，一旦Sybase数据库呈现略微重大的故障就只能放弃失落的数据。咱们数据恢复核心团队通过课题攻关，曾经相熟Sybase数据库的计算和存储规定，有能力解决Sybase数据库常见故障导致的数据失落问题。如果您碰到Sybase数据库故障导致数据失落能够分割咱们。

Oracle数据库故障：北京某公司Oracle数据库误truncate table CM_CHECK_ITEM_HIS，表数据失落，业务查问到该表时报错，数据库备份也不可用，表数据无奈查问。ORACLE数据库Truncate原理：ORACLE会在数据字典和Segment Header中更新表的Data Object ID，理论数据局部的块不会做批改。因为数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不统一，所以ORACLE服务过程在读取全表数据时不会读取到曾经被TRUNCATE的记录（理论仍未被笼罩）。 Oracle数据库数据恢复过程：1、为了爱护用户原Oracle数据库中的数据不被二次毁坏，咱们通过结构与用户雷同的环境和雷同的故障对本案例的Oracle数据库数据恢复的过程进行解说。结构环境： 用Scott用户创立表emp1，屡次间断复制emp表，总记录数为7340032条。只做truncate表emp1的操作，查问该表，Oracle数据库中该表的记录为0条。 2、通过对system表空间文件的剖析，找到truncate数据表的原始数据所在的地位。 3、解析truncate数据表所在的数据文件，找到truncate的数据。4、将truncate的数据表插入到数据库中。5、通过解析system01.dbf文件，北亚数据恢复工程师找到truncate的数据所在的地位，找到被删除的数据。解析truncate数据表所在的数据文件，将truncate的数据插入到数据库中。在Oracle数据库中查找被truncate的数据表，发现数据曾经回来了，备份数据。 6、Exp导出scott用户。

服务器数据恢复环境：Linux零碎，Ext4文件系统；划分为2个分区：1个替换分区和1个文件系统分区。 在剖析理论案例之前，咱们先理解一下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文件系统umount失败，管理员执行fsck查看一致性，后果Ext4文件mount不上(有时也体现为目录变成了文件)，报错信息：mount: wrong fs type, bad option,bad superblock。因为日志和数据不统一而导致失常文件系统数据被笼罩的状况在Ext3、Ext4文件系统中产生的频率较高。因为journal日志文件保留着缓冲数据，数据恢复时能够通过joumal日志文件找到相干信息并重建源文件。装置Linux零碎的硬盘第一个扇区是MBR扇区，通过观察MBR分区表得悉本案例中Linux零碎分为两个分区：替换分区和文件系统分区。北亚数据恢复工程师决定通过joumal日志文件找回失落的数据。通过数据恢复工程师的检测剖析，本案例Ext4文件系统相干信息如下：1、块大小为固定的4KB，即8个扇区。2、超级块(Superblock)起始地位在1024字节处，即2号扇区，大小为2个扇区。3、块组形容表从第一个块开始，即从4096字节处开始。 服务器数据恢复过程：1、首先用数据恢复工具将Ext4文件系统关上，发现0-23扇区的数据(包含超级块和块组描述符)被日志记录所笼罩。Ext3、Ext4文件系统的日志页以C0 3B 39 98结尾。 超级块中能够找到对于块大小的信息。从journal日志中把超级块的备份查找进去，而后再通过数据恢复工具进行超级块信息的查找，其标记是“53ef”。超级块0x18-0x1B处形容块大小，本案例块大小为4KB。 通过超级块查看块大小。 通过数据恢复软件的模板编辑器也能够显示块大小。 2、重建(复原)超级块；因为原文件系统超级块损坏，所以复原文件时要把这部分超级块信息粘贴回去，即放在2号扇区开始或1024字节处。超级块备份的某些局部的数值可能与理论的超级块数值不统一，这种状况下须要通过数据恢复工具的模板管理器进行批改。本案例对超级块所在的第0个块组做了批改。 3、重建(复原)块组形容表；因为局部块组形容表被毁坏，所以须要先在journal日志文件里找到所有块组形容表并把它们粘贴回去。本案例中journal日志文件里的块组描述符表存储在超级块的前面，要找块组形容表能够先找超级块，找到后将块组描述符表内容粘贴到4096字节处。 4、重建(复原)目录；当要复原某个文件夹里的文件时，比方kyproc文件夹里的数据，这些文件夹在WinHex里是不能关上的状态，这意味着这个目录曾经损坏（下图1）。关上其节点信息，发现失常数据被日志填充（下图2）。 找到上一级目录var文件夹，右击点“open”，关上后能看到var文件夹里的所有文件的目录信息。找到要复原的kyproc目录的信息：12 32 EE 00是其i-节点号，10 00示意其目录项长度，06示意其文件名称长度，02示意其文件类型为目录。如下图所示。 在var文件夹的目录块下查找kyproc目录的地位，如下图所示，标红的地位是找到的后果。此地位显示所在块号为62399108。 依据所在块号能够定位kyproc目录相应节点的地位。因为人工补节点比拟繁琐，能够从journal日志文件外面找到其节点信息，把相应的信息粘贴回去。 通过上述办法能够重建(复原)目录。复原目录里的文件也是通过同样的办法从journal日志文件里找到相应的文件的节点信息，找到后粘贴回原来的地位，达到重建(复原)文件的目标。 5、通过数据恢复工程师的致力，终于把用户须要的数据都复原进去，通过数据恢复工程师和用户的核检没有发现问题。本次数据恢复工作实现。

服务器数据恢复环境：IBM某型号服务器，5个SAS硬盘组建RAID5（4个数据盘，1个热备盘）；linux redhat操作系统；下层利用为oa，数据库为oracle；oracle曾经不对本案例中的oa提供后续反对。 服务器故障&初检&复原计划：RAID5中有一块盘离线，但热备盘因为未知起因未被激活rebuild，直到另外一块盘离线导致RAID解体。用户分割咱们数据恢复核心要求复原数据和操作系统。通过数据恢复工程师检测，发现热备盘齐全没有启用，没有发现有物理故障，也没有同步的体现。通过北亚数据恢复工程师团队会诊，确定最终的数据恢复计划：1、敞开服务器，将硬盘标好序号取出。2、将硬盘挂载到只读环境对所有硬盘做镜像备份。后续的数据恢复操作都在镜像文件上进行，防止对原始数据造成二次毁坏。3、基于镜像文件剖析故障RAID5的构造，获取RAID级别、条带规定、条带大小、校验方向、META区域等RAID信息。4、依据获取到的RAID信息搭建虚构的RAID5环境。5、解释虚构磁盘及文件系统。6、检测虚构构造是否正确，如不正确，反复3-5步骤。7、最终确定数据没有问题后依照用户要求回迁数据。如果依然应用原盘，需确定曾经齐全对原盘做过备份之后再重建RAID，而后做回迁。能够应用linux livecd回迁操作系统，也能够在故障服务器上用另外的硬盘装置一个回迁用的操作系统，再进行扇区级别的回迁。 服务器数据恢复过程：1、对故障服务器中所有硬盘进行残缺镜像，镜像过程中发现后掉线的那个硬盘有10-20个坏扇区，其余磁盘均没有发现坏道。2、剖析RAID失去RAID最佳构造、块大小、校验方向等RAID信息，如下图： 3、依据第2步获取到的信息虚构重建RAID后进行数据验证，200M以上的压缩包解压无报错，确定构造正确。4、间接按此构造生成虚构RAID到一块单硬盘上，关上文件系统无显著报错。5、确定备份包平安的前提下经用户批准后利用原盘重建RAID，重建时曾经用全新硬盘更换那块后掉线的曾经损坏的硬盘。将复原好的单盘用USB形式接入故障服务器，用linux SystemRescueCd启动故障服务器。6、通过dd命令进行全盘回写，启动操作系统。7、dd所有数据后，启动操作系统然而无奈进入，报错：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。数据恢复工程师狐疑此文件权限有问题，应用SystemRescueCd重启后查看，后果发现此文件工夫、权限、大小均有显著谬误，这意味着节点损坏。8、从新剖析重组数据中的根分区，定位出错的/sbin/pidof，发现问题是后掉线的那块硬盘坏道所引起的。9、应用其余完整的3个数据盘对后掉线硬盘的损坏区域进行xor补齐。补齐后从新校验文件零碎仍然报谬误，再次查看inode表，发现后掉线硬盘损坏区域有局部节点体现为(下图中55 55 55局部)： 很显著，尽管节点中形容的uid还失常存在，但属性、大小、最后的调配块全副是谬误的。确定无奈找回此损坏节点后只能修复此节点，或复制一个雷同的文件过去。10、对所有可能有错的文件通过日志确定原节点块的节点信息，而后由北亚数据恢复工程师修改。11、修改后从新dd根分区，执行fsck -fn /dev/sda5命令进行检测，仍然报错，如下图： 12、依据报错提醒，在零碎中发现有多个节点共用同样的数据块。通过底层剖析发现存在节点信息的新旧交加问题。13、按节点所属的文件进行区别，革除谬误节点后执行fsck -fn /dev/sda5，仍然有报错但曾经很少。依据谬误提醒发现这些节点多位于doc目录下，不影响系统启动，于是间接应用fsck -fy /dev/sda5命令强行修复。修复后重启零碎，胜利进入零碎桌面。14、启动oracle数据库服务和OA应用软件，一切正常无报错。15、让用户亲自对复原进去的数据和操作系统进行检测，确定没有问题，本次数据恢复工作实现。

服务器数据恢复环境：linux操作系统，文件系统EXT3；12块硬盘组成RAID6；划分3个LUN。 服务器故障&剖析：服务器运行过程中RAID呈现故障不可用，管理员重新分配RAID并进行初始化。初始化超过50%的时候管理员发现状况有异，强行进行初始化，这时候曾经对数据造成不可逆的毁坏。原始RAID6生效后管理员用其中的11块硬盘重新组建RAID5并进行初始化，这种操作对原始数据造成不可逆的损坏。通过北亚数据恢复工程师检测，仅第3个LUN可用一般RAID6复原办法复原出数据，但第3个LUN没有用户想要复原的重要数据，重要数据都在第1个LUN。咱们数据恢复核心接到故障送修时，这个case曾经在多家数据恢复公司做过，但问题仍未解决。 服务器数据恢复过程：1、对故障服务器中的12块硬盘做镜像备份。2、基于镜像文件剖析12块磁盘组建的RAID6的组织构造，剖析11块磁盘重调配RAID5的组织构造。剖析原始RAID6构造比较顺利，但因为底层RAID6和RAID5的大量信息重合，剖析重调配的RAID5的构造就比拟艰难，数据恢复工程师通过近24小时的致力终于把重新分配的RAID5构造搞清楚。3、判断可恢复性，北亚数据恢复工程师钻研编写和校对恢复程序算法，通过程序把12块磁盘中原始数据的第1和第2个LUN别离镜像到搭好的存储环境上。4、通过验证第2个LUN数据没有问题，但第1个LUN后面局部大概有十几MB的数据被毁坏。这前十几MB数据蕴含了EXT3的根目录和第一个块组的I节点，罕用的数据恢复软件复原成果都不现实。5、北亚数据恢复工程师只能手动修复损坏的EXT3文件系统，编写程序对EXT3根目录进行查找并重建根目录和I节点，用文件系统解析程序关上齐全失常。为了保障原始数据的权限和属性，在LINUX下进行简略修复后已能失常挂载，而后在LINUX下把文件拷贝到格式化为EXT3文件系统 的单块磁盘的分区上。这样用户在应用数据时不再须要进行设置，文件目录构造和属性都和原来截然不同。

服务器虚拟化数据恢复环境：Dell某型号服务器；数块STAT硬盘通过raid卡组建的RAID10；Xen Server服务器虚拟化零碎；故障虚拟机操作系统：Windows Server，部署Web服务，存储网站文件和数据库。 服务器虚拟化故障：未知起因导致Xen Server服务器中一台VPS（即Xen Server虚拟机）不可用，虚构磁盘数据失落。 服务器虚拟化数据恢复过程：1、将故障服务器所有磁盘做好标记取出连贯到北亚数据恢复平台，以底层扇区的形式做镜像备份，后续的所有数据恢复操作都在镜像备份文件上进行，防止对原始数据进行二次毁坏。2、基于镜像文件剖析底层数据，北亚数据恢复工程师发现Xen Server服务器中虚拟机磁盘是以LVM构造寄存，每个虚拟机的虚构磁盘都是一个LV，都是采纳的精简模式。LVM的相干信息在Xen Server中都有记录。查看“/etc/lvm/backup/ “目录下的LVM相干信息并没有发现损坏的虚构磁盘信息，数据恢复工程师推断LVM信息曾经被更新。数据恢复工程师只好对底层进行剖析查找未被更新的LVM信息，通过底层剖析果然发现还未更新的LVM信息。如下图： 3、依据未被更新的LVM信息找到了虚构磁盘的数据区域，然而该区域的数据已被毁坏。通过仔细分析最终得出的论断是：虚拟机的虚构磁盘被毁坏造成虚拟机中的操作系统和数据失落，导致虚拟机不可用。这类故障很有可能是因为虚拟机遭逢网络攻击或hack入侵后留下恶意程序造成的。数据恢复工程师认真检测这片区域后发现尽管该区域很多数据被毁坏，但留存有很多数据库的页碎片，能够尝试将这些数据库的页碎片拼接成一个可用的数据库。 4、通过北亚数据恢复工程师会诊，最终造成2个复原计划：计划一、复原数据库备份。数据库做过一次备份，数据库备份文件和网站代码被一起压缩到一个RAR压缩包文件中。因而只须要复原出这个压缩包文件即可复原数据库和网站的源代码。计划二：拼数据库碎片。依据数据库构造在底层将找到的数据库的页碎片依照原来的程序拼接起来，而后对数据库进行修复和校检即可复原数据库。 5、实施方案。数据恢复工程师在底层依据RAR压缩包构造找到很多压缩包的数据开始地位，RAR压缩包文件的第一个扇区会记录RAR的文件名。通过匹配从用户那里获知的压缩包文件名和目前找到的压缩包文件名即可找到备份数据库压缩包的开始地位。找到压缩包的开始地位后将此区域的数据恢复进去重命名为一个RAR格局的压缩文件。而后尝试解压此压缩包，后果解压报错。报错如下图所示： 仔细分析复原进去的压缩包，数据恢复工程师发现有局部数据被毁坏。尝试应用RAR修复工具进行修复后解压，后果解压进去的数据只蕴含网站的局部代码，并没有在其中找到数据库的备份文件。由此能够判断数据库备份文件在RAR压缩包中是损坏的。如下是解压进去的局部网站代码： 依据SQL Server数据库的构造在底层剖析数据库的开始地位，故障数据库第9个页会记录本数据库的数据库名。通过在用户获取到的数据库名称在底层找到此数据库的开始地位。因为故障数据库的每个页中都会记录数据库页编号和文件号，依据这个特色北亚数据恢复工程师编写程序在底层扫描合乎数据库页的数据，而后将扫描进去的碎片按程序重组成一个残缺MDF文件，再通过MDF校验程序检测MDF文件是否残缺。重建的MDF文件如下： 6、搭建环境验证数据。检测MDF文件没有发现问题，由北亚数据库工程师搭建数据库环境，将重组的MDF文件附加到搭建好的数据库环境中。查问相干表的数据是否失常，最新数据是否存在。 验证数据：数据库须要联合网站代码能力更好地验证数据库。因为网站源代码大部分曾经毁坏，备份的源代码也只有局部能够用。用户从网站开发服务商拿到网站代码从新搭建环境，而后将复原进去的数据库在环境中配置好进行验证。经用户重复验证后确认数据库没有问题。

服务器数据恢复环境：两块SAS硬盘组成raid0。 服务器故障：raid0中的一块硬盘的指示灯显示黄色，这块硬盘被raid卡踢出，raid解体。 服务器数据恢复过程：1、把硬盘做好标记而后从服务器中取出，通过SAS HBA的形式直连到windows环境下，在磁盘治理中将硬盘标记为脱机状态，保障后续操作过程中硬盘只读，防止毁坏原始数据。2、将两个硬盘底层扇区做残缺镜像。通过文件系统剖析盘序和条带大小等raid信息，基于这些信息应用工具将原始raid环境搭建进去并解析ntfs文件系统，这时候曾经能够看到数据。 问题：如果间接把数据拷贝进去，那么原始的零碎和利用都须要重新部署。因为没有软件服务商的反对，施行起来有难度。所以北亚数据恢复工程师采取的办法是把搭建起来的raid残缺迁徙到新的raid环境中，这样解决就能够复原到和故障产生前一样的状态。服务器raid数据回迁案例：1、因为本案例服务器的前面板由raid卡来治理，在前面板插入新硬盘是不会间接被零碎辨认的，须要在raid卡下创立raid后才能够应用，而且限于单盘容量的问题，不能采纳这个计划。2、因为服务器前面板有个DVD光驱，服务器光驱和主板采纳sata通道连贯，能够通过连贯光驱的sata接口连贯一块sata硬盘，而后在pe或者linux live cd模式下就能够回迁数据了，这是速度最快的办法。然而在筹备施行的时候发现这个机器应用的sata不是规范大小接口类型，而是mini sata，因为没有现成的转接卡，所以这个方法也临时行不通。3、其实在数据量不大的时候也能够应用USB形式去做迁徙，然而当初绝大部分服务器的usb接口还是USB2.0，速度慢太消耗工夫，这个办法也不理论。4、最初北亚数据恢复工程师决定抉择通过网络回迁数据。a、通过网络回迁数据须要先启动linux live cd，个别应用linux system rescue cd。在linux启动实现后，用ifconfig命令配置服务器的ip，而后将复原进去的数据放在一个装置有windows server的机器上，在win环境下开启nfs服务（默认是敞开的）“服务管理器--角色--增加角色--勾选文件服务—勾选网络文件系统服务进行装置，第一次装置实现之后须要重启一下计算机”。 b、重启实现后对寄存镜像数据的文件夹进行操作，右键—NFS共享标签页外面勾选共享此文件夹，在权限外面勾选容许根目录拜访，拜访类型抉择读写。 c、Win端的设置实现后再看linux端的设置，ifconfig查看以后网络配置。 因为须要调配个ip给linux端，在本案例中咱们给网卡“enp4s0”，调配ip地址10.3.12.3和子网掩码255.0.0.0，应用如下命令：ifconfig enp4s0 10.3.12.3 255.0.0.0。而后再应用ifconfig查看ip地址。 d、配置好ip之后查看网络是否连通，命令：ping 10.1.1.1，而后查看10.1.1.1机器上的NFS共享的目录是否可能拜访，命令：showmount –e 10.1.1.1。 e、源机器和指标机器曾经连通，在linux端创立一个目录mkdir /mnt/bysjhf，创立实现后将镜像进去的数据挂载到linux下新创建的文件夹下，命令：mount 10.1.1.1:/data /mnt/bysjhf –o nolock。挂载好之后，查看一下挂载点信息df –k。 f、确定曾经挂载好之后，进入这个文件夹查看一下文件夹里的镜像文件，命令：[email protected] /mnt/bysjhf % ls。查看硬盘及分区信息，命令：fdisk –l。 g、确认好源设施和指标设施之后，进行镜像操作，命令：dd if=/mnt/bysjhf/data.img of=/dev/sda bs=10M。 h、在千兆网环境下NFS的速度可能跑到70M/S，在期待dd实现后，咱们重启服务器并抉择raid疏导，期待的windows启动页面终于呈现了，数据迁徙胜利。

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

一、AIX存储层面相干的常识&AIX环境下LV误删除后的复原计划。 对于AIX而言，PV相当于物理磁盘，一个VG由若干个PV组成，这让咱们能够将容量不同的存储空间组合起来进行统一分配。AIX把同一个VG的所有PV按雷同大小的存储颗粒（PP）进行空间编排。而调配空间时，以若干个PP(可能是不同PV上的)作为汇合，这个汇合就是LV（逻辑卷）。AIX的LVM层VGDA区域有一个固定的PP到LV的映射表，称为PPMAP。每个PV的所有PP从第一个(PP#1)开始，以固定大小的32个字节记录本PP归属于哪个LV。删除AIX中VG的某个LV，在底层就是开释这个LV原先占用的PP，也就是清零之前所有占用PP的32字节PPMAP条目，另外还会做一些诸如LV名称的清理、LV设施摘要信息的清理等工作。 在AIX环境下LV被删除后，不倡议贸然应用mklv命令进行复原。尽管mklv操作在实践上不会革除pp内容区，但在某些状况下还是会损坏数据，比方这种状况：故障前后的PP调配表不雷同但后面的PP表调配正确，这样即便文件系统能够辨认甚至于能够挂上，然而挂上后某些构造可能会呈现谬误，而后被零碎主动修改，这种状况更蹩脚。当然只读形式mount也不是很好的方法。 北亚数据恢复核心给出的AIX环境下LV误删除后的复原计划：1、放弃VG状态，不新建任何LV。2、对VG中所有的PV做残缺镜像。3、在镜像中进行数据提取复原或爱护镜像后以剖析好的PPMAP去重建失落的LV。上述计划的主旨为：所有操作尽可能可回溯。 二、残缺镜像故障卷。 办法一：如果存储本身有卷镜像性能，能够尝试之。办法二：如果AIX环境中有足够空间，放得下须要镜像的pv，能够将pv镜像成文件(或LV)。如果是文件，能够通过FTP等伎俩传进去。(不倡议此办法)办法三：另外构建一台NFS server，以nfs的形式用dd将pv镜像到nfs上。当然如果aix上能够挂载cifs，甚至于间接能够镜像到windows的共享文件夹下。但windows下如果生成大文件，有可能会越来越慢，能够尽量应用WINDOWS2008或抉择其余计划。办法四：倡议的计划。具体为构建块设施mapping至aix环境，间接以块设施至块设施的办法进行镜像。可抉择的块设施有fc lun，iscsi等。如果不具备fc环境的撑持，至多iscsi(能够是软iscsi)是足够好的计划。 以windows端做iscsi target，AIX环境做iscsi initiator为例，上面为故障卷镜像过程：1、配置网络环境，让AIX与WINDOWS能够通过网络通讯。2、在WINDOWS上搭建ISCSI TARGET，以starwind为例，创立了一个名称为pv0的iscsi磁盘。 3、返回aix平台，确定是否装置iscsi initiator。输出lsdev | grep iscsi，如果提醒“iscsi0 Available iSCSI Protocol Device” 就示意ISCSI客户端曾经装置，设施号是iscsi0。输出lslpp -L | grep -i iscsi确认是否曾经装置了ISCSI软件包。如未装置，先装置iscsi initiator。4、批改aix环境中/etc/iscsi/targets文件，在文件内容最初减少一行（本例中windows iscsi target的ip是192.168.1.9，iqn见上图）。5、在aix平台执行cfgmgr -l iscsi0 (见步骤3中的设施号)，从新扫描iscsi设施。6、lspv查看是否辨认到iscsi设施。后果如下： 能够看到hdisk3曾经辨认到，lsattr -El hdisk3查看设施详细情况，后果为： 能够看到iscsi设施细节，还能够通过bootinfo -s hdisk3查看指标iscsi容量是否正确(单位为MB，本例仅为演示，只创立了个大小为4GB的ISCSI存储卷)。 7、应用dd命令对故障存储做残缺镜像(倡议应用块设施门路进行镜像)：ddif=/dev/rhdisk0 of=/dev/rhdisk3  bs=4096k  conv=noerror,sync。 三、AIX环境下LV误删除数据恢复计划。 在残缺备份故障PV后就能够开始复原数据了。有3种计划能够对数据进行复原：计划一：剖析失去原LV的PPMAP，之后通过mklv -m <指定的ppmap文件>的形式重建与原先LV雷同的调配表，以激活原LV，从而复原数据。计划二：剖析失去原LV的PPMAP，间接通过第三方软件(北亚开发有WINDOWS端的JFS2文件系统解释软件)进行JFS2文件系统解释。如果是裸设施(RAW)，可残缺读出后再从新按块写回。计划三：如果原LV中存储的是ORACLE数据库，能够针对oracle数据文件的特色，从所有PP中提取碎片并组合好所有的特定数据文件，再以Oracle数据库的劫难复原办法复原oracle数据库系统。

虚拟机数据恢复环境：某IDC机房VMware ESXi虚拟化零碎，连贯多个LUN。 虚拟机故障&剖析：管理员因误删除其中一个LUN中的一台虚拟机，这个LUN部署无数台虚拟机，装置的都是Windows Server操作系统。被误删的这台虚拟机上运行SQL Server数据库和寄存一些重要的其它格式文件。用户分割咱们数据恢复核心要求复原此虚拟机上所有文件，并且可能失常启动和工作。VMware ESX/ESXi的文件系统VMFS是一种高性能文件系统，针对虚拟机这类重负荷工作进行性能优化，已靠近裸设施的性能。ESX/ESXi上的虚拟机及其他文件都是存储于VMFS文件系统中。咱们数据恢复核心工程师团队对VMFS文件系统进行过专门的课题钻研，目前已把握支流版本VMFS的底层构造，对于ESX/ESXi的VMFS损坏、误删除虚拟机、VMFS 跨区卷损坏、底层RAID损坏等波及到VMFS文件系统的数据劫难复原有独有的技术和教训，已胜利复原了上千案例的ESX/ESXi数据。 虚拟机数据恢复过程：1、本案例的数据恢复工作次要依附咱们数据恢复核心自研的Frombyte Recovery For ESX实现，Frombyte Recovery For ESX 扫描进去的虚构磁盘中显示了原来虚构磁盘的大小、所属操作系统类型、原来虚构磁盘的模式（厚/薄）、调配状态信息。下图就是扫描进去的虚构磁盘，有两个虚构磁盘的调配状态已标识为’NO’，阐明这两个很有可能就是管理员误删除的虚拟机中的虚构磁盘。 2、应用Frombyte Recovery For ESX复原出这两个虚构磁盘（这两个虚构磁盘别离为原零碎的C盘和D盘），导入到本地部署有ESXi的服务器上，通过非凡办法将虚拟机失常加载到虚构磁盘后，虚拟机曾经能够失常启动。下图中就是在本地ESXi上启动的虚拟机。 3、管理员亲自对复原进去的虚拟机、虚拟机上运行的数据库以及虚拟机上的其余格式文件进行验证，没有发现问题，确认复原进去的数据残缺可用，本次数据恢复胜利。 数据安全Tips:1、重要的数据不要存储在单盘上，组建一组RAID是比拟好的数据存储形式。2、肯定要做好备份，备份包不要放到同一存储媒介上。即便寄存在同一媒介也不要放到同一分区下。3、呈现故障后千万不要重复尝试各种复原或者修复的操作，最须要做的就是尽快对故障硬盘做残缺备份。4、尽可能抉择业余正规的数据恢复服务商进行解决，不正规业余的机构或集体会无心或无意地对故障盘数据进行二次毁坏。

服务器数据恢复环境：ProLiant某型号服务器；6块SAS硬盘组成RAID5；WINDOWS SERVER操作系统；存储企业部门外部文件。 服务器故障&剖析：呈现几次意外断电后，故障服务器再次重启后RAID报错，提醒无奈找到存储设备，进入RAID治理模块界面后死机，管理员重启故障服务器后问题仍旧。用户分割到咱们数据恢复核心寻求帮忙。本案例的服务器故障属于服务器意外断电导致RAID模块损坏（RAID模块损坏故障包含RAID治理信息失落和RAID模块硬件损坏），这类服务器故障状况咱们数据恢复核心碰到过很多。失常状况下，RAID创立实现后治理模块的信息就不会轻易扭转。但治理模块的信息毕竟是可批改的，意外断电这种突发状况就很容易导致治理模块的信息被篡改甚至失落，屡次断电甚至会对RAID模块硬件造成物理挫伤，让服务器失去对硬盘进行RAID治理的中间层模块。本案例中对RAID模块的操作导致死机的故障就很可能是RAID模块硬件损坏造成的，这种状况下无奈通过惯例办法读取到故障服务器中6块硬盘的数据，只能通过专门的数据恢复技术来复原其中的数据。 服务器数据恢复过程：1、硬件工程师对故障服务器中的6块SAS硬盘进行物理故障检测，所有硬盘均可失常读取，没有发现物理故障。2、对故障服务器中的6块硬盘做镜像备份，后续的数据恢复操作都在镜像文件上进行，防止对原始数据造成二次损坏。3、基于镜像备份文件剖析故障RAID5的构造，北亚服务器数据恢复工程师联合故障服务器文件系统存储规定获取到故障RAID5的盘序、数据块大小及校验形式，通过这些raid相干信息虚构重组原始RAID5。4、逻辑校验新构建RAID5中的数据，确认新构建RAID5所有参数准确无误后，北亚数据恢复工程师对最重要的数据进行齐全验证。5、让用户对复原进去的数据进行验证，确认数据残缺可用。6、将所有数据迁徙至用户筹备好的存储。 服务器数据安全Tips：1、保障机房供电稳固，以缩小断电，电压不稳等电源问题对服务器和存储的挫伤。2、为要害服务器及存储装备UPS，这样在机房意外断电的状况下至多能保障外围业务能持续失常工作，为找到应急解决方案博得贵重的工夫。3、对服务器和存储设备定期进行查看，对运行状态进行评估以决定是否须要降级硬件或者零碎。提前制订好突发数据劫难的应急解决计划，以升高数据劫难带来的损失。

存储数据恢复环境：一台HP EVA某型号存储，2组扩大柜；12块FATA磁盘+10个FC磁盘，不确定LUN数量；WINDOWS操作系统，存储历史案例审理资料。存储故障起因不明。 存储故障初检&剖析：1、通过和管理员沟通后，服务器数据恢复工程师得悉数据呈现问题后该存储未再应用。依照HP-EVA的常见故障能够初步推断该故障存储中的数据恢复的可能性较高。2、将EVA主机及扩大柜关机，将所有硬盘标好地位和序号并取出。将硬盘挂接到北亚EVA算法平台上。 3、进入WINDOWS环境，用工具查看磁盘状况，所有磁盘均可失常辨认。 4、查看每块磁盘信息，发现FC磁盘存在PV HEAD，而FATA磁盘均无PV HEAD。FC磁盘中存储的Metadata仅形容了一个RSS组组成的LUN，成员为所有FC磁盘。FATA磁盘中残留的LUN信息至多蕴含5组信息。通过下面的信息，北亚数据恢复工程师推断因为某种原因，由FATA磁盘组成的DISK GROUP内划分的VDISK都被删除，并且所有FATA磁盘UNGROUP。5、通过剖析FATA磁盘上保留的Metadata能够初步判断数据的可复原率较高。 存储数据恢复过程：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进行复原。6、由用户对最终复原进去的数据进行验证，确认数据残缺无效。

存储数据恢复环境：EqualLogic PS系列存储；16块SAS硬盘组成RAID5；VMFS文件系统，寄存虚拟机文件；存储系统下层分4个卷。 存储故障：存储设备有两块磁盘的指示灯显示黄色，存储不可用。存储设备曾经过保，用户分割咱们数据恢复核心寻求帮忙。 存储数据恢复过程：1、硬件工程师对故障存储的16块磁盘进行了硬件检测，发现其中2块磁盘呈现坏道，SMART的谬误冗余级别超过阀值。2、把其余14块检测失常的硬盘进行全盘镜像，数据恢复工程师对2块有坏道的硬盘进行修复并生成镜像文件。 3、收集故障存储的日志信息，通过日志剖析两块磁盘的掉线工夫，判断哪块硬盘外面的数据是最新的，应用有最新数据的硬盘进行数据恢复。  4、剖析16块磁盘的raid信息，北亚数据恢复工程师利用获取到的raid信息把16块盘虚构还原到最后的RAID状态，通过位图信息在虚构进去的RAID中把4个lun全副提取进去。 5、依据底层构造剖析，北亚数据恢复工程师把4个VMFS的文件系统进行跨区卷组合，导出用户数据，并验证虚拟机是否失常。 6、将卷里的文件都拷贝进去，通过网络共享的形式验证复原进去的虚拟机，虚拟机都能够失常启动。把虚拟机文件移交给客户并亲自验证没有发现问题。 7、通过一直的底层剖析和测试，终于在要求的工夫内将数据完全恢复并交付给用户。

某品牌EqualLogic系列存储介绍：某品牌EqualLogic系列存储能够通过连贯串口先对存储进行初始化。通过浏览器登录配置的ip地址，账号默认：grpadmin，明码默认：grpadmin；也能够通过串口登陆查看状态。 卷的划分和拜访如下图： 底层构造：以9块盘组建磁盘阵列为例，该存储在创立RAID的时候，会默认调配一块热备盘，并不是全局热备。用8块盘组成一组RAID5，在RAID5上以15M大小为一个块进行切块划分。把所有大小为15M的块放到一个存储池外面，而后从存储池里重新分配。存储池能够跨阵列重新组合成Mdisk，别离映射给不同的主机。组合形式如下图： 依据Vdisk中的位图信息进行15M块的排列组合，多个15M块组合成一个或者几个Mdisk，而后把Mdisk调配给主机进行文件系统的创立。位图信息如下图： 存储故障&数据恢复办法：EqualLogic系列存储故障少数状况下是硬盘或者控制器的问题导致的，故障体现为存储不能拜访。1、在呈现问题之后先用串口连贯，查看硬盘状态，找到出问题的硬盘，命令如下： raidtool -Zraidtool –zdiskview –j 2、通过网口收集日志信息进行剖析，命令如下：telnet –f c:\eqlog.txt groupIPsu exec bashuname –aifconfig –adiskview –jdiskview –Qdmesgrstatdbtooleqllogmgr –r 3、抓取到日志文件后进行剖析，在进行其余操作前把所有硬盘备份，防止出现后续操作不可逆。

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

服务器数据恢复环境：某品牌POWEREDGE某型号服务器，6块SCSI硬盘组建RAID5磁盘阵列；LINUX REDHAT操作系统，EXT3文件系统。 服务器故障&剖析：通过检测以及和用户沟通后，服务器数据恢复工程师初步推断故障RAID5开始有一块硬盘离线，然而管理员没有发现，直到另一块硬盘掉线后RAID解体，服务器不可用。管理员分割原厂工程师，原厂工程师倡议将其中一块掉线硬盘强制上线，但同时强调此操作的危险。管理员将其中一块掉线硬盘强制上线后，发现操作系统启动异样，于是马上关掉服务器，分割咱们数据恢复核心寻求帮忙。RAID5阵列2块硬盘离线导致阵列解体这类故障十分广泛。硬盘强制上线具备较大危险，上线谬误会导致RAID控制器主动做出一些不可逆操作，再次进入操作系统后，因为文件系统不统一会导致修复，最终可能会造成全副硬盘数据不统一。本案例就是这类故障。 服务器数据恢复过程：1、残缺镜像备份故障RAID中所有硬盘，在镜像过程中发现多块没有下线的硬盘存在坏道，只是RAID没有辨认进去临时没有下线。2、基于镜像文件剖析原RAID组成构造，依据原RAID信息构建虚构RAID环境。3、验证RAID构造的正确性，北亚数据恢复工程师修改局部前期被毁坏的构造，而后将数据导出到另一存储。4、用新硬盘在故障服务器上搭建新RAID5磁盘阵列。5、将数据迁徙至新RAID阵列。6、用户亲自对复原进去的数据进行验证没有发现问题，确认本次复原数据残缺无效。

服务器数据恢复环境：一台StorageWorks磁盘阵列设施，5块硬盘组建一组RAID5磁盘阵列。 服务器故障&剖析：RAID5磁盘阵列中的一块硬盘掉线，因为RAID5的个性，磁盘阵列持续失常工作，然而没隔多久RAID解体不可用。用户分割的培修人员在没有理解故障RAID5的详细情况的前提下，将其余4块硬盘组建成一组全新的RAID5并实现了数据同步，导致原始数据全副失落。故障设施的Smart Array存储控制器在创立一组新的RAID5时会默认全盘重建所有块校验。也就是说在组成RAID5的任一条带中，总有一个校验块的数据是创立时生成的，这种全盘重建所有块校验的操作绝对于原始数据来说是破坏性的。通过北亚数据恢复工程师的剖析，后生成的4块盘RAID5是依照双循环、64K块大小、条带换校验次数16的形式组建的，也就是说4块磁盘中每隔3M便会有1M的数据是谬误的。原先的5块盘RAID5是双循环、128K块大小、16次条带换校验。要复原数据必须先修复掉线的那块硬盘，复原率取决于那块磁盘掉线之后的数据又变更了多少。通过北亚数据恢复工程师团队会诊，最终确定下来的复原计划是：通过对5块盘RAID5和4块盘RAID5的组成构造差异性剖析，用之前掉线的盘从新补回重建4盘RAID5时毁坏的校验信息，而后再虚构重组RAID5，解释文件系统并导出文件。 服务器数据恢复过程：1、数据恢复工程师对故障RAID5中所有硬盘进行镜像备份。2、剖析2次RAID5磁盘阵列的数据，获取5块盘RAID5和4块盘RAID5的构造。3、剖析5块盘RAID5和4块盘RAID5的组成构造差别，北亚数据恢复工程师编写校验修改程序。依照先前的5块盘RAID5构造虚构重组RAID，生成重组RAID后的镜像文件。4、修改重组RAID后的镜像文件零碎谬误。5、将局部分区导出数据，在无错的前提下将局部分区齐全镜像到新空间。6、由用户亲自对复原进去的数据进行测试、验收，确认复原进去的数据残缺无效。

数据库数据恢复环境：4个硬盘组成Oracle ASM磁盘组。 数据库故障&剖析：ASM磁盘组掉线 ，ASM实例不能mount。管理员分割咱们数据恢复核心进行oracle数据库的数据恢复。对故障ASM磁盘组的磁盘进行剖析。北亚数据库数据恢复工程师取出ASM元数据进行剖析发现ASM存储元数据损坏，diskgroup无奈mount。能够尝试重组ASM存储空间，而后从ASM磁盘组中导出数据库文件，检测导出的数据库文件并对损坏的数据库文件进行修复。如果导出的数据库文件完整，就能够利用从ASM磁盘组中导出的数据库文件启动数据库。如果数据库文件损坏，能够从底层解析这些数据库文件，而后将解析进去的数据库文件导入到新的数据库中，复原数据。 数据库数据恢复过程：1、通过底层获取ASM元数据，重组ASM存储空间。2、应用北亚自研的ASM解析工具解析ASM构造，取得ASM的数据文件。 3、应用北亚自研的oracle文件检测工具检测ASM磁盘组中的数据库文件。 4、应用北亚自研的oracle解析工具解析所有数据文件中的数据记录，按用户导入到新的数据库中。 5、重组ASM存储空间，从底层解析ASM磁盘，导出数据库文件。从底层解析这些数据库文件，按用户将数据导入到新的数据库中。 6、抽查数据表进行验证数据，最终确认数据完全恢复。

服务器数据恢复环境：Windows Server服务器，部署Hyper-V虚拟机环境；虚拟机的硬盘文件和配置文件寄存在某托管核心的存储设备中；存储设备中4块硬盘组成阵列存储虚拟机的数据文件，单块4T硬盘存储虚拟机数据文件备份。 服务器故障剖析&复原计划：因为存储设备中的虚拟机数据文件失落，整个Hyper-V服务瘫痪，虚拟机无奈应用。管理员分割咱们数据恢复核心寻求帮忙，北亚数据恢复工程师团队对故障存储服务器进行检测：1、检测故障存储服务器没有发现物理故障，硬盘均能够失常工作。2、查看操作系统没有发现出错过程，排除因操作系统问题导致的数据失落。3、剖析失落数据的硬盘的文件系统：关上失常，排除入侵毁坏的可能性。在剖析硬盘的文件系统过程中发现此文件系统的元文件创建工夫与数据失落的工夫相吻合。发现这种状况，数据恢复工程师初步判断文件系统被人为重写，即分区被格式化。4、查看系统日志发现数据失落的当天和之前的系统日志已被清空，审核日志和服务日志却并未清空，这种状况合乎人为操作的特色。格式化分区的操作只记录在系统日志中，这也与人为毁坏的特色相符。5、剖析硬盘的底层数据，发现硬盘底层中须要复原的系统日志已被新的日志记录笼罩，无奈复原。6、对操作系统中的所有分区进行剖析，发现故障存储中只有两个分区被从新写入文件系统。对两个分区的格式化须要有两个独立的过程，这种针对性的操作更加验证本案例的故障是人为导致。 依据故障剖析论断，北亚数据恢复工程师团队敲定以下复原计划：1、对故障存储中的所有硬盘做全盘备份。2、剖析每个硬盘的数据获取到RAID相干信息，重组RAID阵列。3、对重组的阵列进行剖析，看是否找到原有的文件索引项及对应的数据区。4、核查查找到的文件索引项是否合乎用户数据，并核查相应的数据区有无毁坏。5、将扫描到的文件索引项碎片拼接成一个残缺的目录构造。6、依据拼接好的目录项去底层复原对应的数据，并检查数据是否正确。7、核查数据没问题后复原所有数据。 服务器数据恢复过程：1、备份用户数据。因为数据全副都放在托管核心的存储设备中，因而只须要复原存储设备中的数据即可。将故障存储中所有的硬盘编号后从存储设备中取出交给硬件工程师检测硬盘物理故障。检测实现后对每块硬盘做全盘镜像，应用工具将硬盘中所有扇区镜像到备份硬盘中。 2、重组RAID磁盘阵列。剖析每块硬盘数据获取RAID相干信息（条带大小，条带走向等），依据这些信息重组RAID。 3、扫描旧的文件索引项。剖析硬盘底层数据，服务器数据恢复工程师发现硬盘底层中残留着许多以前文件系统的目录项及文件索引。通过核查发现这些文件索引指向的数据都是用户失落的文件内容。北亚数据恢复工程师编写了一个提取文件索引项的小程序扫描并提取硬盘中所有存在的文件索引项。 4、剖析扫描到文件索引项。对扫描到的文件索引项进行剖析，北亚数据恢复工程师发现索引项都是不间断的，并且大多是以16K或8K对齐的。失常状况下的文件索引项是间断的，大小为固定的1K，每个文件索引项对应一个文件或目录。而扫描进去的这些不间断且不残缺的文件索引项是无奈失常索引到文件的内容。北亚数据恢复工程师对扫描进去的文件索引项做加工解决，对于被毁坏的缺失文件索引项片段，咱们能够从数据备份盘中去查找。 5、将文件索引项组成残缺的目录构造。依据文件索引项的编号将找到的文件索引项拼接成目录项构造。因为有局部文件索引项被毁坏，因而只能找到大部分文件索引项，但通过这些找到的文件索引项曾经能够拼接出整个目录构造。 6、修复文件系统。用重建好的目录构造替换现有文件系统中的目录构造，应用工具批改局部校验值，而后再应用工具解释这个目录构造即可看到失落的数据。 为了确定数据是否正确，将其中一个最新的VHD文件复原进去并拷贝到一台反对附加VHD的服务器上尝试附加此VHD，附加胜利，查看VHD中最新的数据是否残缺后将所有数据恢复到一块硬盘中。 验证数据：在一台测试服务器上搭建Hyper-V的环境，将复原进去的虚拟机文件连贯到这台服务器上。通过导入虚拟机的形式将复原进去的数据都迁徙到新的Hyper-V环境，让用户来验证所有虚拟机是否残缺。 迁徙数据：在用户验证所有虚拟机没问题后，将所有数据拷贝至用户服务器中。利用导入的形式将虚拟机导入到用户的Hyper-V环境中，导入后没有报错，尝试启动所有虚拟机胜利，没有发现问题。数据恢复实现。

服务器数据恢复环境： 8块盘组成的RAID5磁盘阵列；EXT3文件系统。 服务器故障： 因为误删除导致文件系统中的邮件失落。 服务器数据恢复过程： 一、服务器数据恢复工程师为每块磁盘做镜像, 后续所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘数据造成二次毁坏。 二、剖析数据在硬盘中散布的法则，获取RAID类型、RAID条带大小、每块磁盘的程序等RAID信息。依据获取到的RAID信息重新组建RAID。 三、从组建好的RAID中能够看到下层划分了数个EXT3分区。通过剖析每个EXT3分区中的底层数据，发现一个分区外面有大量的邮件头和nsmail目录。确认此分区就是数据恢复的指标分区，应用工具将此分区导出以便后续解决。 RAID中的所有分区如下： nsmail文件夹： 邮件头示例： 四、复原邮件。 因为EXT3文件系统中的文件被删除后，节点中的文件大小和块指针都被清零，很难通过惯例伎俩去复原。针对EXT3文件系统的特点和邮件文件自身的构造，数据恢复工程师制订复原计划：首先对整个文件系统做扫描，将找到的邮件文件全副取出，而后依据邮件自身记录的收件人、发件人、抄送、主题等信息进行整顿，最初再将数据迁徙到263平台上。 邮件复原的具体过程： 1、北亚数据恢复工程师编写辨认收发人、主题等memi标识的程序和ext3超过48k邮件的提取程序。 2、按小于48k、大于48k两种算法对邮件进行提取。提取的同时生成邮件索引信息库，并提取非自由空间和非邮件区。 3、人工剖析提取的非自由空间和非邮件区，确认是否有脱漏的邮件。如果有脱漏则确定脱漏的起因，调整算法从新进行扫描。 4、反复2、3这2步的过程，直到所有的非自由空间和非邮件区中没有脱漏的邮件。 5、把所有提取出的邮件依照数据库中解析到的收件人和发件人归类，每个账号一个文件夹（内含收件和发件两个文件夹）。 邮件复原后果: 第一次导出邮件68.2G，692,767个文件 第二次改良算法，导出邮件77.2G，720,209个文件。 第三次再次改良算法，导出邮件84.8G，895,032个文件。 总的存储空间是605G，邮件区占用84.8G，剩下的自由空间属于全零区域，必定没有邮件了，非自由空间和非邮件区的垃圾数据有几十G。 通过3次算法改良和记不清多少次的细节增删，通过人工验证在残余的非自由空间和非邮件区曾经无奈找到新的邮件文件。剩下的一些邮件两头碎片无奈进行拼接，而后还有一些芜杂的数据。 邮件两头碎片： 垃圾数据： 验证数据： 验证数据分为两局部，一是邮件数据量的验证，通过对几个已知账号的收件和发件数量的统计大略估算一下邮件的回复比例。二是邮件正确性的验证，用FoxMail关上提取出的邮件，查看内容是否失常。通过用户重复验证，确认本次复原进去的数据残缺无效。 几个账号的数量如下： 一些邮件内容： 移交数据： 配合用户将所有提取出的邮件迁徙到263平台。至此本次数据恢复实现。

服务器RAID5数据恢复环境：存储中12块SCSI硬盘组建RAID5，其中1块热备盘；FreeBSD操作系统，zfs文件系统。 服务器RAID5故障：第6块数据硬盘呈现故障。 服务器RAID5数据恢复过程：一、剖析服务器RAID5。1、初步判断RAID5起始扇区。RAID起始扇区是指RAID内的数据在每块物理盘(创立RAID所用的每块独立的物理硬盘)上的起始地位。起始扇区只存在于一块物理盘，大多数状况是0扇区。找到起始扇区复原raid5的第一步。用WinHex将11块没有问题的硬盘去RAID化。 用WinHex的同步性能将11块盘定位在0扇区，11块盘中只有3块盘（1、2、6号硬盘）的0扇区有“55 AA”标记，这个标记意味着MBR磁盘构造。 剖析哪个硬盘是起始扇区。先看第6块硬盘发现第6块硬盘的结尾显示这是一个GPT头备份并且只有128MB大小。 剩下的1号磁盘和2号磁盘中0扇区有起始扇区或校验。 2、剖析块大小(条带大小)。本案例应用的zfs文件系统，用WinHex同步显示11块物理盘的某个扇区，比方53654656扇区，发现只有1号盘的此扇区跟其余盘显示的不一样，这是位于1号盘的校验区。顺着1号盘53654656扇区高低寻找，找到间断的128个扇区。这128个扇区就是这个RAID5的条带大小。 3、RAID5成员盘的盘序。本案例说的1号盘不肯定就是RAID5的第一个盘，也就是说物理盘程序并不一定就是是RAID的程序，须要进行人工校验能力确定。用WinHex同步定位11块硬盘的53654656扇区，发现1号盘的此扇区与其余盘显示的不同，这个扇区是1号盘的校验区。接着剖析1号盘的下一个条带，即53654656+128=53654784扇区，得出2号盘的这个扇区和其余盘显示的不同，所以2号盘从53654784扇区开始的条带是校验区。以此形式继续下去，接着是3号盘的校验区，4号盘的校验区……得出的校验区如下图所示，“P”字母示意校验区。咱们依照校验区的地位即可失去盘序，而本案例的盘序正好是从1号盘开始顺次递增的。既然晓得了盘序，从第一步剖析晓得了1号盘和2号盘的0扇区为起始扇区或为校验区。对于左构造来说，0扇区是起始扇区的物理盘肯定是RAID5的1号盘；对于右构造来说，0扇区是起始扇区的物理盘肯定是RAID5的2号盘。 4、校验方向。RAID5的根本构造有左同步、左异步、右同步、右异步。左和右是对校验方向来说的，区别如下图所示。本案例中的RAID5很显著是右走向的。 从校验区的走向能够确定整个RAID5的校验方向是右方向。左同步、左异步构造中的校验块都是从最初一块物理盘开始；右同步、右异步构造中的校验块都是从第一块物理盘开始。判断校验方向的办法有两种：一种是先剖析起始扇区，再剖析条带大小，而后是盘序，盘序剖析后校验方向很容易就看进去了。另一种是如果盘序没有确定下来，只确定了起始扇区和条带大小，能够采纳反推法。应用反推法分析，在盘序还没有确定下来的状况下，由这个校验区能够算出某个盘中第一个校验区是第几个条带。具体方法如下：找到某个校验区，比方3号盘的53654912扇区，用这个扇区对条带大小与盘数的乘积取余。即53654912MOD(128 * 12)=256计算的后果等于256，示意256号扇区是校验。而位于此扇区的3号盘处于第3个条带，并且是第3个条带的开始扇区，包含256号扇区在内的当前的128个扇区是3号盘的第一个校验区。接着判断1号盘下一个条带，1号盘下一个条带显示3号盘是校验区。接着判断3号盘下一个条带，3号盘下一个条带显示3号盘是校验区。由此能够确定校验方向。 5、数据走向。同步异步说的是数据的走向。异步构造中，各条带组内的数据块均由低号盘向高号盘顺次写入。同步构造中，每个条带组内第一个数据块写在校验块所在物理盘的下一个物理盘，若前面还有物理盘，则程序往后写，若校验块所在物理盘后没有物理盘，则从校验块所在物理盘后面的物理盘开始从低号盘向高号盘程序写入。 以下是本案例RAID5的剖析过程(已确定此RAID5是右构造)。 1.从“数据块A”动手。 首先查看“数据块A”开端扇区的数据，而后再查看“数据块B”和“数据块C”开始扇区的数据。如果“数据块A” 开端扇区的数据可能与“数据块B” 开始扇区的数据连接，则该RAID5属于异步构造。如果“数据块A” 开端扇区的数据可能与“数据块C” 开始扇区的数据连接，则该RAID5属于同步构造。2.从“数据块A”动手。 首先查看“数据块A”开端扇区的数据，而后再查看“数据块B”和“数据块C”开始扇区的数据。如果“数据块A” 开端扇区的数据可能与“数据块B” 开始扇区的数据连接，则该RAID5属于异步构造。如果“数据块A” 开端扇区的数据可能与“数据块C” 开始扇区的数据连接，则该RAID5属于同步构造。3.从“数据块A”动手。 首先查看“数据块A”开端扇区的数据，而后再查看“数据块B”和“数据块C”开始扇区的数据。如果“数据块A” 开端扇区的数据可能与“数据块B” 开始扇区的数据连接，则该RAID5属于同步构造。如果“数据块A” 开端扇区的数据可能与“数据块C” 开始扇区的数据连接，则该RAID5属于异步构造。4.从“数据块A”动手。 首先查看“数据块A”开端扇区的数据，而后再查看“数据块B”和“数据块C”开始扇区的数据。如果“数据块A” 开端扇区的数据可能与“数据块B” 开始扇区的数据连接，则该RAID5属于异步构造。如果“数据块A” 开端扇区的数据可能与“数据块C” 开始扇区的数据连接，则该RAID5属于同步构造。 二、重组RAID5。 从下面的步骤中咱们曾经解析出RAID5的一些重要信息，依据这些信息，咱们就能够重组RAID5了。 上面咱们用UFS Explorer工具关上并增加这11块硬盘。 将1.dsk增加到了左侧Connected storages里。 把RAID5的10块盘都增加进去。点击Build RAID选项，按照RAID5的盘序把10块盘都增加进去，开始组建RAID5。 第6块盘因为呈现故障，所以要剔除，并在其地位增加时补一个空缺，并持续程序增加完其它硬盘。点击标红框地位处的按钮，增加空缺硬盘。 接着抉择校验方向和数据走向，本实例条带大小为28个扇区，即65KB，右异步构造。因而设置如下所示。 接着点击Build按钮，呈现如下所示。点击find查找，抉择zfs文件系统。 呈现了如下图所示的正在组建的RAID5。

服务器数据恢复环境：宁夏某单位一台浪潮服务器；6块SAS硬盘组成的RAID5；下层分了1个卷，寄存Oracle数据库文件。 服务器故障：RAID5中两块硬盘故障离线，指示灯显示黄色，RAID5瘫痪，服务器不可用。因为服务器曾经过保，用户分割到咱们数据恢复核心寻求帮忙。 服务器数据恢复过程：1、服务器硬件工程师对故障RAID5的6块硬盘进行硬件故障检测，发现掉线的2块硬盘有大量坏道、SMART的谬误冗余级别超过阈值。2、服务器数据恢复工程师对4块失常硬盘进行全盘镜像备份，应用业余工具对2块故障硬盘进行了复原并生成镜像文件。后续的数据恢复操作都是基于镜像文件，防止对原始数据造成二次损坏。 3、基于镜像文件剖析两块故障硬盘的掉线工夫，从而确定数据最新的那块硬盘，用数据最新的那块硬盘进行数据恢复。 4、基于镜像文件北亚服务器数据恢复工程师剖析故障RAID5的相干信息，依据剖析获取到的相干RAID信息虚构重构出原始RAID5。通过位图信息在虚构进去的RAID5中把lun全副提取进去。5、服务器数据恢复工程师对底层构造进行剖析并导出用户数据，验证数据库文件是否失常。6、将卷里的文件都拷贝进去交付给Oracle数据库工程师。Oracle数据库工程师对数据库文件进行验证并导入数据，数据库文件校验失常，导入也没有问题。用户确认复原进去的数据残缺无效。7、把数据库从新备份并把数据库文件和备份文件移交给用户，数据恢复实现。 服务器RAID数据安全Tips：1、服务器产生故障后，用户切忌再对服务器进行任何操作，也切忌随便取出硬盘，免得弄乱程序减少前期数据恢复的难度。2、如果曾经取出硬盘，标记好硬盘的程序。3、求助业余正规的服务器数据恢复机构，切忌因为图便宜而轻易交付数据恢复的工作。

存储数据恢复环境：一台挂载在Windows server操作系统服务器上的IBM某型号存储；划分了一个NTFS文件系统的分区，寄存oracle数据库。 存储故障：服务器宕机，管理员重启服务器，零碎主动进行磁盘扫描修复，管理员强制关机断开了存储和服务器的连贯，导致这台存储的文件系统损坏，报错信息为“文件或目录损坏且无奈读取”。 存储数据恢复过程：1、首先须要对故障存储的所有硬盘做镜像备份，后续的数据恢复操作都是在镜像文件上进行，防止对原数据造成二次挫伤。北亚数据恢复工程师通过光纤交换机把故障存储整个卷镜像到筹备好的存储设备上，原存储设备交还给用户。2、剖析镜像卷的底层数据发现故障产生的起因是MFT表的文件记录的80属性的data runs在操作系统自检时被截断，并且分区内多达几千万个文件数据，包含几十个G的mft文件，文件有大量的碎片。3、应用数据恢复软件进行扫描的后果不现实，扫描后果只有1/3而且目录构造都是凌乱的。服务器数据恢复工程师改为手工剖析。4、收集剖析所有的mft表碎片信息，基于这些信息改写80属性的data runs。这种手工分析方法工作量非常宏大，然而通过数据恢复工程师致力，最终把本来的6个多T的数据残缺复原进去，目录构造也是残缺的。通过用户亲自验证，确认复原进去的数据残缺可用。 小贴士：1、服务器操作系统在进行磁盘扫描修复过程中切忌强制关机，如果切实进不了零碎能够求助专业人士。2、服务器产生故障后防止对须要复原数据的服务器进行写入和批改数据的操作。3、求助业余服务器数据恢复机构，切忌在未备份的状况下对服务器进行任何操作。

存储数据恢复环境：北京某医院的一台EMC某型号存储raid5解体；存储中12块硬盘组成raid5（2块热备盘）；下层一个lun调配给sun小机，下层文件系统是ZFS。 存储故障：故障存储中有2块硬盘呈现故障，但只有1块热备盘激活胜利，raid5阵列瘫痪，下层lun无奈应用。 存储数据恢复过程：1、数据恢复工程师检测故障存储中所有磁盘没有发现物理故障和坏道。2、应用工具将故障存储中的全副磁盘镜像备份。源磁盘的扇区大小是520字节，须要把所有备份数据做520字节 to 512字节的转换。3、因为所有硬盘不存在物理故障和坏道，能够初步判断故障是由局部磁盘读写不稳固造成的。因为EMC控制器有着十分严格的查看磁盘策略，如果磁盘呈现性能不稳固的状况就会被EMC控制器判断为坏盘并踢出raid阵列。当raid中掉盘数量超过该raid所容许最大掉盘数量，raid瘫痪，导致raid的下层lun不可用。4、EMC存储的LUN都是基于RAID的，因而须要先剖析底层RAID的信息，而后依据剖析获取到的信息重构原始RAID。对所有硬盘数据剖析，发现8号盘和11号盘齐全没有数据，8号盘和11号盘都是Hot Spare，但8号盘的Hot Spare替换了5号坏盘。因而判断8号盘（Hot Spare）尽管胜利激活，但RAID阵列中还缺失一块硬盘，所以数据没有同步到8号硬盘中。持续剖析其余10块硬盘的数据分布法则、RAID条带的大小和每块磁盘的程序。 5、基于剖析获取到的RAID信息，通过北亚自主开发的RAID虚构程序将原始RAID虚构进去。但因为故障RAID总共掉线两块盘，因而须要判断这两块硬盘的掉线程序。仔细分析所有硬盘中的数据发现有一块硬盘在同一个条带上的数据和其余硬盘显著不统一，因而能够初步判断此盘是最先掉线的，通过北亚自主开发的RAID校验程序检测这个条带发现除掉方才剖析的那块硬盘得出的数据是最好的，因而能够确定最先掉线的硬盘。6、因为EMC存储的LUN是基于RAID的，RAID重组进去后，数据恢复工程师开始剖析LUN在RAID中的调配信息以及LUN调配的数据块MAP。下层只有一个LUN，只须要剖析一份LUN信息，而后依据剖析进去的信息应用raid恢复程序解释LUN的数据MAP并导出LUN的所有数据。7、利用北亚自主开发的ZFS文件系统解释程序对生成的LUN做文件系统解释，然而在解释某些文件系统元文件的时候有报错。于是开发工程师对该ZFS文件系统解释程序做debug调试并分析程序报错起因。文件系统工程师剖析ZFS文件系统是否因为版本起因导致程序不反对。通过数小时的剖析与调试，后果发现存储忽然解体导致ZFS文件系统中某些元文件损坏，从而导致解释报错。8、通过剖析确认存储瘫痪导致局部文件系统元文件损坏，只有修复好这些损坏的文件系统元文件能力失常解析ZFS文件系统。通过剖析损坏的元文件发现，存储瘫痪的同时ZFS文件系统正在进行IO操作，所以导致局部文件系统元文件没有更新或者损坏。数据恢复工程师对这些损坏的元文件进行手工修复，保障ZFS文件系统可能失常解析。9、修复好的ZFS文件系统做解析，解析所有文件节点及目录构造。由用户方工程师对数据进行验证，验证没有发现问题，数据残缺可用。

服务器数据恢复环境：HP StorageWorks某型号存储；虚拟化平台为vmware exsi；10块磁盘组成raid5(有1块热备盘)。 服务器故障：raid5阵列中两块硬盘指示灯变黄掉线，无奈读取序列号，在SAS扩展卡上无奈读取。故障产生后管理员把故障设施拿到咱们数据恢复核心进行检测。 服务器数据恢复过程：1、服务器数据恢复工程师把其余失常硬盘连贯到北亚镜像服务器上进行扇区级镜像备份。 2、判断故障raid5阵列中硬盘故障状况是逻辑故障还是物理故障。首先将坏盘连贯到内部的SAS扩展卡，加电后通过硬盘工作声音能够判断硬盘电机可能起转，然而磁头没有寻道。硬件工程师把硬盘PCB拆下来并清洁HDA组件的氧化局部，将PCB还原后加电故障仍旧。和用户沟通后将热备盘的PCB装置到故障盘，再将故障盘PCB上的ROM芯片替换到热备盘的PCB下面，加电后硬盘电机起转和磁头寻道声音失常，然而在寻道完结后有显著的敲盘声，判断磁头损坏。在和用户沟通后，将热备盘的磁头拆下装置到故障盘。在无尘工作间对故障盘进行收盘更换磁头，对故障盘进行检测，发现故障盘不能辨认，数据无奈读取。因为有两块故障盘，之前修复失败的是其中一块，再次和用户沟通后尝试对另一块故障盘进行修复操作。和第一块故障盘一样，第二块故障盘仍旧是磁头损坏，因为用户的OEM盘价格昂贵，于是在网上购买ST原厂的雷同型号硬盘进行磁头更换。这块故障硬盘的磁头更换后可能失常辨认，于是将这块修复好的故障盘所有扇区残缺镜像到一块雷同容量的备份盘中。 3、重组RAID5。 用工具把镜像文件解析成磁盘。所有磁盘的0扇区都有“55 AA”标记。 0x01C2H处示意该分区的类型，“05”代表这是一个扩大分区。因而从0扇区看这是一个不失常的MBR分区构造。 持续往下找，别离在9号盘和8号盘找到了“55 AA”的标记。通过9号盘查问后果能够看到，这是一个失常的MBR分区，其0x01C6处数值示意指向的下一个扇区为GPT的头部。 通过8号盘查问后果能够看到其0x01C6处数值代表指向下一个扇区。然而下一个扇区很显著不是GPT的头部。 由此能够确定9号盘是第一块盘，8号盘可能是最初一块盘。GPT分区所在扇区起始于172032扇区，因而初步判断LUN的起始扇区是172032扇区。 判断条带(stripe)大小。条带也称块，是RAID解决数据的根本单元，不同RAID的条带大小是不一样的。RAID5的1个条带组中有1个校验区，1个校验区的大小等于1个条带的大小。针对这个RAID-5案例做分析判断本案例的一个条带大小是1024个扇区。 判断RAID5成员盘盘序。依照1024扇区宰割，使一个记录为一个条带的大小。所有9块盘跳到同一记录283123。 当所有盘都定位到同一地位时，通过比照就能够判断出校验区的走向，继而确定整个RAID5的走向。之前曾经判断出9号盘是第一块盘了，把9号盘放在第一个地位就能够判断走向了。最终确定RAID5为左走向，盘序为9，2，3，4，10，1，7，8，5。 曾经初步确定了LUN的起始扇区是172032扇区。用工具跳到172032扇区察看各硬盘理论状况。如果172032扇区是LUN的起始扇区，那么这个扇区所属条带中的5号盘应该是校验区，然而此条带中却显示8号盘是测验区。因为本案例RAID5是左走向，5号盘的校验区应该在172032-1024=171008扇区，即上一个条带。跳转到171008扇区发现校验区为5号盘。因而能够确定LUN的起始扇区为171008扇区。 重组RAID5。应用工具依照确定的盘序组好增加进去。抉择RAID55，Stripe size 512KB，左异步。 点击Build进行重组。因为数据从1024 * 8=8192个扇区开始，若工具没有跳转到此扇区的性能，那么刚组好的RAID必须和一个文件再进行一次Build重组操作。RAID的起始扇区(Start sectors)抉择8192，这个文件能够任意抉择起始扇区和大小(Count sectors)，如下图1和图2所示。下图3是组好的RAID5。 移交数据：整个RAID5重建好后，分割用户验收数据，通过用户亲自对复原进去的数据进行验证后确定数据没问题。依据用户要求把数据移交到用户带来的新盘上。本次数据恢复实现。

服务器数据恢复环境： H P DL系列某型号服务器； 三个SAS硬盘组成raid磁盘阵列；D分区寄存数据库，E分区寄存备份。 服务器故障： RAID阵列中硬盘产生故障，状态灯显示红色，RAID瘫痪。D分区辨认不进去；E分区可辨认，然而从E分区拷贝备份文件报错。管理员重启服务器，先离线的硬盘上线开始同步数据。然而同步没有实现被强制关机，之后服务器就没有再开机。管理员分割咱们数据恢复核心进行数据恢复。 服务器数据恢复过程： 1、为了确保原始数据的平安，服务器数据恢复工程师对故障服务器中所有磁盘以只读形式做镜像备份。RAID阵列中的3个硬盘都能够失常读取，通过检测没有发现有坏道，以只读形式镜像备份日志。 2、对镜像文件进行剖析获取故障RAID相干信息，利用获取到的RAID信息重组raid并进行异或校验，然而只有局部校验通过。因为管理员重启服务器导致离线硬盘上线同步，这一步操作会损坏数据，局部校验通过意味着有局部数据被损坏。 3、服务器数据恢复工程师尝试在3个硬盘别离离线状态下提取数据，后果发现每块盘离线状态下所提取的数据都是一样的。 4、服务器数据恢复工程师针对E分区中的dat文件进行剖析，后果发现两个备份文件都有损坏。 5、北亚服务器数据恢复工程师剖析聚合dat碎片并验证dat数据的完整性，后果底层构造显示有损坏。 6、对D分区的数据文件进行剖析&扫描，然而数据文件目录不可见。 7、对D分区自在空间数据页进行扫描发现较间断的数据片段，碎片可用。北亚数据恢复工程师对文件碎片进行剖析和聚合并验证数据文件碎片的完整性和有效性。 8、提取备份文件中的数据记录到新建的数据库中。 9、通过下层利用连贯数据库并验证数据的可用性，数据库文件能够失常加载，下层利用中的用户账号失常，能够进行失常的数据查问。本次数据恢复实现。