数据恢复

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

服务器数据恢复环境： IBM DS系列存储服务器；16块容量600G的FC硬盘。 故障： 存储服务器前面板10号和13号硬盘故障灯亮，存储映射到redhat上的卷挂载不上，业务下线。服务器管理员分割北亚数据恢复核心进行服务器数据恢复。 服务器数据备份和测试过程： 1、到现场后，北亚数据恢复工程师通过storage manager连贯到存储查看以后存储状态，存储报告逻辑卷状态失败。物理磁盘状态：6号盘报告“正告”，10号和13号盘报告“失败”。 2、通过storage manager将以后存储的残缺日志备份下来，通过解析备份进去的存储日志，北亚数据恢复工程师获取了对于逻辑卷构造的局部信息。 3、将16块FC盘粘贴标签，依照原始槽位号注销后从存储中移除，应用FC盘镜像设施“R510+SUN3510”对16块FC盘进行粗略测试，16块盘均能失常辨认。别离检测16块盘的SMART状态，发现6号盘的SMART状态为“正告”，和在IBM storage manager中报告统一。 4、在windows环境下将设施辨认进去的FC盘在磁盘管理器中标记为脱机状态，为原始磁盘提供一个写爱护性能。北亚数据恢复工程师而后应用软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到逻辑磁盘并以文件模式保留。在镜像过程中发现6号磁盘的镜像速度很慢，联合先前对硬盘SMART状态检测时发现的问题综合判断，6号盘应该存在大量损坏以及不稳固扇区，导致个别应用软件无奈对其进行操作。 5、应用坏道硬盘镜像设施对6号硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现6号盘的坏道并不多，然而存在大量的读取响应工夫长的不稳固扇区。于是北亚数据恢复工程师调整6号盘的拷贝策略，将“遇到坏道跳过扇区数”和“响应等待时间”等参数做批改后持续对6号盘进行镜像操作。同时察看残余盘镜像的状况。 6、实现全副镜像后查看日志，发现在storage manager和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不法则的坏道散布，通过应用软件定位到指标镜像文件剖析坏道列表发现，ext3文件系统的局部要害源数据信息曾经被坏道毁坏，只能期待6号盘镜像结束后，通过同一条带进行xor以及依据文件系统上下文关系的形式手动修复被损坏的文件系统。 7、6号盘镜像实现，然而先前为了最大限度备份出无效扇区以及为了爱护磁头设置的拷贝策略会主动跳过一些不稳固扇区，所以当初的镜像是不残缺的。北亚数据恢复工程师调整拷贝策略，持续镜像被跳过的扇区，实现6号盘所有扇区的全副镜像。 8、失去了所有硬盘的物理扇区镜像，在平台下应用软件将所有镜像文件全副开展，依据对ext3文件系统的逆向以及日志文件的剖析，北亚数据恢复工程师获取到了16块FC盘在存储中的盘序、RAID的块大小、RAID的校验走向和形式等信息。北亚数据恢复工程师尝试通过软件的形式虚构重组RAID，RAID搭建实现后进一步解析ext3文件系统，通过和服务器管理员沟通提取出了一些oracle的dmp文件，服务器管理员尝试进行复原。 9、在dmp复原的过程中，数据库报告imp-0008谬误，通过仔细分析导入dmp文件的日志文件，北亚数据恢复工程师发现复原的dmp文件存在问题所以导致dmp导入数据失败。北亚数据恢复工程师立即从新剖析raid构造，进一步确定ext3文件系统被毁坏的水平。通过数小时的致力，从新复原dmp文件和dbf原始库文件，将复原进去的dmp文件移交给服务器管理员进行数据导入测试，测试没有发现问题。而后对复原进去的dbf原始库文件进行校验检测，所有文件均能通过测试。 服务器数据库复原流程： 1、 拷贝数据库文件到原数据库服务器，门路为/home/oracle/tmp/syntong作为备份。在根目录下创立了一个oradata文件夹，把备份的整个syntong文件夹拷贝到oradata目录下，而后更改oradata文件夹及其所有文件的属组和权限。 2、备份原数据库环境，包含ORACLE_HOME下product文件夹下的相干文件。配置监听，应用原机中的splplus连贯到数据库。尝试启动数据库到nomount状态。进行根本状态查问后，确认环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查问没有问题。启动数据库到open状态。呈现报错： 3、通过进一步的检测和剖析，北亚数据恢复工程师判断此故障为管制文件和数据文件信息不统一，这是一类因断电或忽然关机等引起的常见故障。 4、对数据库文件进行一一检测，检测到所有数据库文件没有物理损毁。 5、在mount状态下，北亚数据恢复工程师对管制文件进行备份，alter database backup controlfile to trace as ' /backup/controlfile'；对备份的管制文件进行查看批改，获得其中的重建管制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。 6、 敞开数据库，删除/oradata/syntong/下的3个管制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。 7、重建管制文件实现后，间接启动数据库，报错，须要进一步解决。 而后执行复原命令： 做介质复原，直到返回报告，复原实现。 8、尝试open数据库。SQL> alter database open resetlogs; 9、  数据库启动胜利。把原来temp表空间的数据文件退出到对应的temp表空间中。 10、对数据库进行各种惯例查看，没有任何谬误。 11、进行emp备份。全库备份实现，没有报错。将应用程序连贯到数据库，进行利用层面的数据验证。 12、数据验证完结，数据库修复实现，数据恢复胜利。

服务器数据恢复环境：XFS文件系统服务器；MD1200磁盘柜+RAID卡+Linux零碎；riad5+划分了两个分区的80T左右的LUN；2T大小的sdc1分区通过LVM扩容的形式退出到了root_lv中；sdc2分区为XFS文件系统。 服务器故障：服务器重装系统后sdc磁盘分区扭转，原先的sdc2分区失落，无法访问。管理员分割北亚数据恢复核心进行数据恢复。 服务器数据恢复过程：依照惯例复原流程，首先对服务器进行只读模式备份，北亚数据恢复工程师对每块磁盘做了镜像备份后将原服务器偿还，在备份数据上进行数据分析和数据恢复操作。1、对镜像文件进行剖析，查找服务器raid磁盘阵列的硬盘程序、条带大小等信息；2、北亚数据恢复工程师应用北亚自研的数据恢复工具对raid阵列进行虚构重组，虚构重组出raid构造；3、在虚构重组出的raid阵列中定位到xfs文件系统的分区起始地位；4、校验xfs文件系统的完整性及正确性，经校验，北亚数据恢复工程师发现文件系统没有异样；5、修复xfs文件系统的超级块构造； 修复实现的超级块 6、北亚数据恢复工程师对xfs文件系统中失落的节点及目录项进行修复； 修复实现的根节点 重做的目录项 7、修复实现后，北亚数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。 修复实现的目录构造 数据恢复后果：在本次服务器数据恢复过程中，北亚数据恢复工程师对失落的xfs文件系统进行检测后发现文件系统头部的超级块及局部节点、目录项失落。北亚数据恢复工程师依据超级块备份及文件系统中的目录树结构，对超级块进行修复还原，对失落的节点、目录项进行修补、重构之后，文件系统中的数据即可胜利复原。因为在数据失落后没有对服务器进行其余操作，数据及文件系统被最大限度地保留了下来，通过北亚数据恢复工程师的数据分析及数据恢复操作，最终残缺复原服务器内的所有数据，并经服务器管理员验证无误，本次数据恢复胜利。

故障：误操作将linux文件系统装入到Ocfs2文件系统的数据卷上，原始Ocfs2文件系统被格式化成为Ext4文件系统。服务器管理员分割北亚数据恢复核心进行数据恢复。 故障剖析：因为Ext4文件系统每隔几百兆就会写入文件系统的原始信息，数据可能受到肯定水平的毁坏。 ocfs2文件系统数据恢复过程：1、备份数据——将存储以只读模式映射给北亚数据恢复核心的备份服务器。应用dd，Winhex等业余备份工具将映射到备份服务器中的数据做全副镜像。做齐全部镜像后，将所有存储配置及链路还原至初始状态，之后数据恢复均不对原始硬盘进行任何操作。 2、剖析ocfs文件系统构造——找到ocfs2文件系统的超级块，通过剖析超级块，北亚数据恢复工程师获取ocfs2文件系统的根本构造信息。通过服务器管理员提供的虚构磁盘文件名称，北亚数据恢复工程师查找到虚构磁盘文件的目录项，继而找到所对应的所有一级索引项和二级索引项，并利用北亚数据恢复核心自主开发的文件系统解析程序，对已备份的数据进行文件系统解析。ocfs2文件系统的索引项构造如下：一级索引项 二级索引项 3、修复ocfs文件系统修复损坏的文件系统，对原始Ocfs2文件系统做一致性检测，并对损坏的区域进行人工修复。 4、复原数据利用北亚数据恢复核心自主开发的针对Ocfs2不残缺文件系统的解析工具对已修复的Ocfs2文件系统进行解析。依据文件系统剖析的后果，北亚数据恢复工程师编写对应的数据提取程序，最大水平的复原每一个虚构磁盘文件，并对复原的每一个虚构磁盘文件进行一致性检测。 5、文件检测与修复对复原进去的虚构磁盘文件进行解析，验证虚构磁盘文件是否有谬误，并修复损坏的文件。复原其中的用户文件，对已复原的用户文件进行一致性检测，并修复损坏的文件。 数据验证：1、验证虚拟机针对用户比拟重要的虚拟机做验证，大部分虚拟机都能够开机到登录界面。小局部虚拟机开机蓝屏或开机检测磁盘，通过光盘修复之后都能够启动。局部虚拟机开机截图如下： 有一台虚拟机磁盘文件复原之后，通过解析发现该虚拟机中没有数据，持续对该虚拟机的磁盘文件进行剖析，发现该文件索引项存在，然而索引构造并不多，数据量也很少，有可能存在人为清零或批改的状况，也可能虚拟机本来就没有多少数据。 2、验证数据库对重要虚拟机中的数据库做验证，发现数据库都失常。局部数据库可能与应用程序对接有肯定问题，服务器管理员分割应用程序原厂的技术人员对应用程序进行修复之后，数据库都能够失常应用。 移交数据：因为工夫紧迫，北亚数据恢复工程师应用业余工具顺次导出ocfs2中的虚拟机，而后将虚构磁盘数据带到客户现场。在现场应用网线将R510服务器接入到客户外部的网络当中，而后通过NFS共享，将虚拟机磁盘文件上传到客户的服务器上，而后通过ovm虚拟机管理工具进行虚拟机挂载，实现数据移交。 数据恢复总结：基于ext4文件系统的个性，Ext4文件系统每隔几百兆会写入文件系统的原始信息，对原始数据造成肯定的毁坏。所以，本次数据恢复过程中，对ocfs2文件构造的剖析占用了比拟多的工夫。

误操作导致数据库数据失落是最常见的数据库故障。如果有最新备份的状况下，误删除数据后复原备份数据即可。当然也会有非凡情况如：数据库备份无奈应用、还原报错等。北亚数据恢复工程师为大家介绍的是一例oracle数据库误truncate table 后的数据库复原案例。如果您碰到误操作导致数据失落，备份又恰好无奈应用的状况能够参考这个数据恢复计划。 Truncate工作原理：失常状况下oracle会通过Segment Header及数据字典对表的Data Object ID进行更新，具体到存储数据局部的块实际上并未被批改。在oracle服务在进行全表数据读取时，因为数据字典和Data Object ID与理论存储的数据块内容不统一，而不会读取到被truncate的内容记录，这也就是数据库复原数据的要害。 数据库数据恢复过程：在本案例演示中，北亚数据恢复工程师结构了一个故障。1、结构故障的软硬件设施如下：Os：windows server；数据库版本：最新版本的64位的win_oracle。2、Scott用户创立表emp1，复制emp表，间断复制屡次，总记录数为：7340032条。随后truncate表emp1。此时查问该表，数据库中该表的记录为0条。见下图： 3、北亚数据恢复工程师关上数据库文件的底层数据，对system表空间文件进行剖析，找到truncate表的原始数据所在的地位，见下图： 4、解析表所在的数据文件数据库，找到truncate的数据；5、将truncate的数据库插入到数据库中。 数据恢复后果 ： 通过解析system01.dbf文件，北亚数据恢复工程师找到truncate的数据所在的地位，找到被删除的数据。解析表所在的数据文件，将truncate的数据插入到数据库中。在数据库中，查找被truncate，发现数据回来了，间接备份数据。见下图： Exp导出scott用户；见下图：

环境： Dell PowerEdge服务器；XenServer虚拟化平台；4块希捷2T STAT硬盘用RAID卡组成的RAID10；XenServer虚拟机操作系统：Windows Server零碎；虚拟机磁盘：1个10G系统盘和1个5G数据盘，部署的Web服务器（ASP +SQL）。 故障： 服务器忽然断电导致服务器中一台XenServer虚拟机不可用，虚构磁盘文件失落，服务器管理员分割北亚数据恢复核心寻求帮忙。 故障检测和剖析： 1、拿到原始数据盘后，北亚数据恢复工程师将原始盘连贯到北亚数据恢复服务器上，筹备超过原始盘总容量的空间作为备份原始盘数据应用，将原始盘以磁盘底层扇区的形式镜像到备份空间上，当前操作都在备份数据上操作，以确保原始盘数据安全。 2、剖析底层数据，北亚数据恢复工程师发现XenServer中虚拟机的磁盘都是以LVM构造寄存，即每个虚拟机的虚构磁盘都是一个LV，虚构磁盘模式是精简模式。LVM的相干信息在Xen Server中都有记录，查看“/etc/lvm/backup/frombtye.com “下LVM的相干信息发现并没有存在损坏的虚构磁盘信息，因而北亚数据恢复工程师判断LVM的信息曾经被更新了。因而，北亚数据恢复工程师只能接着剖析底层看是否找到未被更新的LVM信息，通过一番致力，终于在底层发现还未更新的LVM信息。如下图： 3、依据获取到的未被更新的LVM信息找到虚构磁盘存放数据的区域，发现该区域的数据已被毁坏。北亚数据恢复工程师通过剖析后发现，造成虚拟机不可用的起因是虚拟机的虚构磁盘被毁坏，虚拟机中的操作系统和数据失落。这种状况很有可能是由虚拟机遭逢网络攻击或入侵后留下恶意程序造成的。认真核查这片区域后，北亚工程师发现尽管该区域很多数据被毁坏，但还是找到很多数据库的页碎片，能够尝试将这些数据库的页碎片拼接成一个可用的数据库。 服务器数据恢复过程： 1、数据恢复计划一依照计划一的思路进行底层剖析，依据RAR压缩包的构造能够找到很多压缩包的数据开始地位，而RAR压缩包文件的第一个扇区中会记录此RAR的文件名。因而通过从管理员那里获知的备份数据库的压缩包文件名和目前找到的压缩包地位的文件名相匹配，可找到备份数据库压缩包的开始地位。找到压缩包的地位后仔细分析这片区域的数据，而后将此区域的数据恢复进去重命名为一个RAR格局的压缩文件，尝试解压此压缩包，解压报错。报错如下图所示： 仔细分析复原进去的压缩包，北亚数据恢复工程师发现有局部数据被毁坏，因而解压的时候报错。尝试应用RAR的修复工具看是否疏忽谬误，解压进去局部数据。后果修复实现之后解压进去的数据只有网站的局部代码，并没有发现数据库的备份文件。因而能够判断数据库备份文件在RAR压缩包中是损坏的。 如下是解压进去的局部网站代码： 2、数据恢复计划二因为计划一并没有胜利将数据库复原进去，因而采纳计划二来复原数据。依据SQL Server数据库的构造去底层剖析数据库的开始地位。在SQL Server数据库的构造中，第9个页会记录本数据库的数据库名。因而从服务器管理员那里获知到数据库名称之后，北亚数据恢复工程师再剖析底层找到此数据库的开始地位。因为在SQL Server数据库的每个页中都会记录数据库页编号以及文件号，北亚数据恢复工程师依据这些特色编写程序去底层扫描合乎数据库页的数据。而后将扫描进去的碎片按程序重组成一个残缺MDF文件，再通过MDF校验程序检测整个MDF文件是否残缺。重建的MDF文件如下： 验证数据： 通过检测确定复原进去的数据没问题之后，由北亚工程师搭建数据库环境，将重组后的数据库附加到搭建好的数据库环境中，查问相干表数据是否失常，查问最新数据是否存在。截图如下： 因为数据库须要联合网站代码能力更好的验证数据库的完整性。管理员从网站开发商那里拿到网站代码搭建好环境，而后将复原进去的数据库配置好后去验证，没有发现问题，本次数据恢复胜利。

在大数据和互联网时代，数据就是生产力，数据安全是古代企业最重要资产之一。对于一些企业比方互联网公司来说，服务器中的数据就是所有。置信很多企业都有过数据恢复的经验。那么在企业经营过程中有没有什么方法尽量避免服务器中的数据失落造成重大损失呢？北亚数据恢复工程师通过这篇文章为大家介绍一些防止数据失落造成重大损失的措施，心愿对不理解的敌人们有用，对于相熟的敌人们也能起到一个揭示的作用。 一、长期保持定期对数据进行备份每个公司都会对重要数据做备份，然而长期保持定期做备份的企业可能就不多了。看到这里，想一想本人有没有做到这点。如果可能定期备份数据，在遇到像硬软件故障、误删除、断电等导致的数据失落状况时候能够应用备份来复原数据，防止重大损失。入行工夫长一点的服务器管理员或者运维应该对「3-2-1 准则」不生疏，这个准则就是在备份数据时创立3个备份包，将备份包存储在2个不同的硬件设施上，1个备份包放在异地存储。如果能做到这点，基本上就能防止数据失落造成重大损失这种状况产生。每个企业有不同的备份形式：本地备份、异地备份、云端备份等。 二、定期检查和保护硬件设施定期对硬件设施进行查看、保护，能够无效防止因为硬件故障导致的数据失落。 三、建设防火墙和爱护机制建设防火墙和防御机制是必不可少的措施，防止歹意攻打、零碎入侵等对企业数据造成毁坏的非法行为，爱护服务器数据安全。 四、数据失落后及时进行数据恢复如果曾经呈现了数据被误删除、物理故障等导致数据失落的状况，而且没有可用的备份数据时，须要第一工夫把设施关停断电，如果有条件的能够抉择关机保留，而后分割正规业余的数据恢复公司进行数据恢复，以最大限度的复原数据，防止造成更重大的损失。

环境：IBM FlashSystem存储；raid5；windows，ntfs；64块900G的SAS硬盘。 故障：存储中一块硬盘产生故障离线，热备盘启用替换，与离线盘同一组Mdisk中的另一块磁盘也离线，导致热备盘同步失败，这组Mdisk生效，整个通用卷无奈应用，阵列瘫痪。管理员分割北亚数据恢复核心寻求帮忙，复原的数据次要是dcm图像文件。 数据恢复过程：1、在数据恢复后期将数据备份，防止数据恢复过程中毁坏原始数据。在数据恢复平台上挂载故障存储必须以只读形式挂载对扇区进行备份。备份实现出具具体报告，将原故障存储复原到起始状态后交回给管理员，对所有数据恢复的操作均不波及原有故障设施。 2、剖析并且重组Mdisk。依据原有的配置信息，将硬盘依照Mdisk组分类。通过对每一组Mdisk中硬盘剖析失去相干的raid信息，北亚数据恢复工程师用北亚自研的数据恢复软件对Mdisk进行虚构重组。 3、pool剖析。通过对所有Mdisk剖析获取pool的相干信息，用北亚自研的数据恢复软件虚构重组出pool。 4、修复文件系统。校验NTFS文件系统的正确性及完整性。修复NTFS文件系统。 5、对文件系统进行解析并且提取数据。 验证数据：让服务器管理员亲自验证所有数据，若有发现新问题则从新测验上述所有数据恢复的过程，直到所有复原进去的数据残缺无效。

环境：某品牌X3850系列服务器；linux操作系统；4块SAS接口硬盘组成raid5阵列。 服务器故障：服务器运行过程中瘫痪，管理员对原零碎进行了重新安装，数据失落。失落的数据包含：数据库、办公文档、代码文件等。分割北亚数据恢复核心进行数据恢复。北亚数据恢复工程师对这台服务器进行了检测，发现因为重装系统，逻辑卷被扭转，文件系统被毁坏，呈现了空白超级块，数据失落。 服务器数据恢复过程：1、北亚数据恢复工程师首先对服务器进行了底层数据分析，通过节点间的互相关联关系剖析出被毁坏前的节点信息，对节点进行数据修复。2、北亚数据恢复工程师对文件系统中的文件进行调整，生成B+树并导出所有节点。3、北亚数据恢复工程师对导出的节点进行排查，去除对数据恢复有效的节点，而后从新排序生成对应的地位信息。4、北亚数据恢复工程师依照对应地位信息查问节点，生成树的索引信息，随后生成超级块信息。5、北亚数据恢复工程师在虚拟机下创立快照，将修复后的数据挂载到新创建好的快照下，能够看到文件内容。6、北亚数据恢复工程师在虚拟机环境下持续对文件目录地位、名称等信息进行修改，查找文件头、文件标记地位进行修复，最终复原所有数据。 服务器数据恢复后果：分割服务器管理员亲自对数据进行验证，确认复原的数据残缺、正确，本次数据恢复实现。

环境： MD1200磁盘柜raid5磁盘阵列raid卡100T容量，3个分区XFS文件系统linux操作系统 故障： 管理员重装服务器操作系统，装置完零碎后发现服务器的磁盘分区产生扭转，其中一个分区隐没，其余分区也均不可拜访。分割北亚数据恢复核心寻求帮忙。 数据恢复过程： 1、为防止在数据恢复过程中毁坏原始服务器数据，北亚数据恢复工程师对服务器原始数据进行了盘对盘的镜像备份，而后将原始硬盘偿还管理员。 2、剖析raid信息，提取其中的数据包含：服务器硬盘盘序、raid阵列条带大小、raid块排列程序等。提取这些信息的目标是为了重组raid。 3、剖析提取出重组raid所需的数据后应用北亚自研数据恢复工具进行虚构重组，在重组出的raid阵列内定位分区起始地位，提取出整个xfs文件系统的数据，对提取出的数据进行完整性验证和准确性验证，发现均没有异样。 4、修复xfs文件系统：修复xfs文件系统的超级块构造，对xfs文件系统中失落的节点及目录项进行修复。 修复实现的超级块 修复实现的根节点 重做的目录项 5、修复实现后，北亚数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。 服务器数据恢复后果： 通过北亚数据恢复工程师对提取的文件进行验证，所有文件失常，让服务器管理员亲自进行数据进行验证，确认本次数据恢复后果残缺、精确，本次数据恢复胜利。

环境：16块600GB的SAS硬盘组成的RAID5；VMFS文件系统，寄存虚拟机文件；在存储系统的下层一共分了4个卷，其中3个卷都是1.5TB，另外1个卷为1TB。 故障：因磁盘故障而导致存储不可用，服务器曾经过保，管理员分割北亚数据恢复核心复原数据。 数据恢复过程：1、北亚数据恢复工程师对16块硬盘做了硬件检测，发现其中的2块盘呈现坏道，SMART的谬误冗余级别曾经超过阈值。把14块失常硬盘进行全盘镜像，用北亚数据恢复核心自研的数据恢复工具对2块有坏道的硬盘进行了数据恢复并做了镜像备份。2、北亚数据恢复工程师先收集该存储的日志信息。对收集到的日志信息进行剖析，查明两块故障硬盘的掉线工夫，找出数据最新的那块硬盘，用最新数据的硬盘进行数据恢复。 3、北亚数据恢复工程师对16块盘进行虚构还原到之前的RAID状态，通过位图信息在虚构进去的RAID中把4个lun全副提取进去。依据底层构造剖析，把4个VMFS的文件系统进行跨区卷组合，导出数据，并验证虚拟机是否失常。 4、北亚数据恢复工程师将卷里的文件都拷贝进去，通过网络共享的形式验证复原进去的虚拟机，虚拟机都能够失常启动。通过管理员的亲自验证，复原数据残缺无效。 通过漫长的底层剖析和一直的测试，一共耗时7天将数据残缺复原。北亚数据恢复工程师对DEll存储的原理和算法曾经攻关，DEll存储的数据恢复都能够找北亚数据恢复核心。

环境：EMC存储服务器；10块硬盘组成RAID5磁盘阵列。 故障：RAID5磁盘阵列有3个硬盘因为故障离线导致服务器瘫痪。管理员增加了新硬盘做rebuild，然而没有拔掉掉线的硬盘，服务器中有3块多余硬盘。 数据恢复过程：1、服务器管理员初步判断服务器瘫痪是因为阵列中硬盘呈现硬件故障导致的，于是将所有硬盘交给北亚数据恢复核心进行了物理检测。北亚硬件工程师对服务器中所有硬盘进行检测后没有发现硬盘存在物理故障，把硬盘移交给北亚数据恢复工程师进行解决。 2、对所有磁盘进行镜像备份后，北亚数据恢复工程师开始对服务器raid构造进行剖析。 3、北亚数据恢复工程师发现该服务器中的硬盘每512字节就多减少了一个8字节的校验，也就是每扇区520字节。这种状况下持续进行raid构造剖析将十分困难。北亚数据恢复工程师编写了一个小程序将8字节的校验去掉，不便前期的工作。 4、用这个小程序将所有磁盘都转换实现后，北亚数据恢复工程师持续剖析RAID的构造。因为多了3块旧盘，须要通过比拟每块磁盘，即其中会有两块磁盘后面的一部分雷同，而这两块磁盘中会有一个是旧的，因为旧的数据量没有新盘多，所以数据量少的就是旧盘，依照这种思路能够分辨出新盘和旧盘。这样的磁盘会有3对。 5、此服务器应用的是NTFS文件系统，能够用MFT弄清楚RAID构造。搞清楚RAID构造后，北亚数据恢复工程师发现这是一个双循环RAID 5。因而无奈借助数据恢复工具重组RAID，北亚数据恢复工程师只好通过其余形式重组raid阵列。 6、重组RAID后发现数据不是最新的。北亚数据恢复工程师推断呈现这种问题的起因是：RAID5第一块硬盘掉线的时候管理员没有及时发现，没有及时增加新的硬盘做rebuild，导致服务器运行一段时间后又有一块硬盘掉线了，才造成整个RAID不可用。所以还须要找出一块旧的磁盘，能力生成最新的数据。 7、北亚数据恢复工程师采纳穷举加校验的办法进行剖析，即假如某个磁盘是掉线的，踢掉磁盘后重组RAID，但不是生成全副的数据，而是只生成后面5G的数据，咱们只须要查看这个索引表的位图的信息是否正确就能够判断此RAID是否正确。如果正确，那么生成此RAID的数据即可实现RAID的重组。通过3天的致力，数据最终完全恢复。

分布式存储环境： Dell PowerEdge机架式服务器；数据库类型：Hbase、Hive； 16台物理服务器。 故障： 16台服务器节点，在每台物理服务器上均匀有3台虚拟机，在虚拟机上配置分布式，下层部署的hbase数据库和hive数据库。数据库底层文件被误删除，导致数据库不可用。管理员分割北亚数据恢复核心复原hbase和hive数据库的数据。 分布式存储数据恢复过程： 通过现场对环境的简略检测，北亚数据恢复工程师发现虚拟机还能够失常启动，然而虚拟机上部署的数据库块文件失落。块文件失落之后整个集群环境没有新的数据写入，底层数据损坏可能性比拟小，具备较大的可恢复性。因为还没有对底层构造进行剖析，再加上hbase和hive的算法和底层构造十分复杂，复原概率无奈精确判断。 1、备份：A、将存储设备断电、关机，对物理服务器底层做备份。B、从虚拟机层面备份，通过网络间接备份虚拟机底层磁盘文件。C、北亚数据恢复工程师筹备了一台数据恢复服务器，在这台数据恢复服务器上以只读形式挂载原服务器的硬盘，应用北亚磁盘备份工具进行残缺的扇区对扇区的备份。D、备份实现后，由北亚数据恢复工程师提供具体报告，而后将原服务器硬盘交还给管理员。 2、块文件构造剖析：A、对每个虚拟机磁盘的块文件进行剖析；B、剖析文件底层的聚合形式；C、剖析每个磁盘中数据的散布状况。 3、Block文件key剖析：A、定位数据库文件中的key信息；B、提取并解析数据库文件中key信息；C、整合数据库文件key信息。 4、Block文件拼接：A、依据Block文件的key信息提取文件片段；B、对Block文件的片段进行拼接；C、校验拼接后的Block文件的正确性。 5、Block文件导入：A、校验提取出的Block文件完整性及正确性；B、把提取进去的Block文件导入到hbase和hive数据库中。 6、数据验证：A、由管理员对复原进去的数据进行具体验证；B、如发现新问题，则复盘数据恢复过程查找问题起因并加以解决。 北亚数据恢复服务：1、整个过程不会对原盘有任何的写操作，以确保原盘的数据安全；2、尽最大可能保障服务的操作可逆，确保人力可控范畴内操作可回溯；3、提供前期数据保存和服务跟踪；4、以上所有操作在有备份的状况下进行，若不胜利不影响其余数据恢复计划的进行。 本次数据恢复周期：

故障：2个SQL server数据库被加密，无奈应用。数据库MDF、LDF、log日志文件名字被批改，如下图：数据库备份被加密，文件名字被批改。管理员分割北亚数据恢复核心进行数据修复。 数据恢复过程：1、备份数据库。为避免数据恢复过程中对原始数据库造成二次毁坏，北亚数据恢复工程师为每个库做了备份。所有复原数据的操作都在备份上进行, 防止了对原始数据造成损坏的可能。2、应用北亚自研的数据恢复软件关上中病毒的SQL server数据库，发现数据库的头部已被毁坏。3、通过查看，北亚数据恢复工程师确定sqlserver数据库页大小8K，按8K大小切块，向下查找。最终剖析得出，病毒对数据库文件每128K进行一次加密，加密大小为128字节。4、北亚数据恢复工程师关上数据库备份，发现也是每128K进行一次加密，加密大小为128字节。5、向下搜寻数据库页起始标记01 0F， 北亚数据恢复工程师发现此处没有被加密。通过剖析发现数据库与数据库备份加密形式一样，每128K进行一次加密，加密大小为128字节。因为数据库备份头部记录备份信息，数据库页起始向下偏移，因而数据库中加密的页与数据库备份中加密的页正好错开。6、修复加密数据库。北亚数据恢复工程师联合数据库备份对数据库中加密的页进行修复，通过数据库管理工具附加批改好的数据库，并进行查问验证，后经管理员验证，数据没有问题。

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

环境：16块硬盘组成的raid6磁盘阵列。 故障：磁盘阵列中有一块硬盘因为物理故障掉线，导致虚拟机无奈失常应用，局部分区失落。管理员重启服务器后发现下层数据仍然不在，分割北亚数据恢复核心进行数据恢复。 数据恢复过程：1、通过对服务器下层数据进行检测，北亚数据恢复工程师判断故障是硬盘掉线导致的下层虚拟机文件系统被毁坏。个别这种状况能够思考通过拼接文件碎片的办法来复原失落的数据。 2、对现有的文件碎片进行拼接。拼接原理为：通过fbb源文件位图信息中的512M位图信息进行拼接。通常状况下，服务器下层虚拟机损坏的元文件指针类型不同会导致最终指向的数据索引地位不同。当初虚拟机的元文件曾经损坏，通过服务器现有数据是无奈确认指针类型的指向。如果指针最终指向的地位不是fbb元文件区域，则通过拼接文件碎片办法将无奈复原数据。 3、既然拼接文件碎片的办法行不通，只能通过逆向验证的办法，假如下层虚拟机的损坏元文件指针的确指向fbb中的512M位图，依照这一思路北亚数据恢复工程师决定间接对服务器底层数据进行扫描和拼接，在拼接过程中一直进行数据测验。 4、北亚数据恢复工程师在数据拼接时发现了两个目录，通过验证发现这两个目录十分相似，北亚数据恢复工程师判断其中一个目录里的数据为备份数据。于是北亚工程师具体比照了这2个类似目录中的目录、文件和底层数据，发现这两个目录中的数据完全一致，确认其中之一为备份数据，因而只需复原这两个目录中的任意一个的数据即可。 5、北亚数据恢复工程师对其中的一个目录进行持续拼接后发现文件系统被严重破坏，所有的文件都无奈失常关上和应用。只能对另外一个目录进行拼接和复原。北亚数据恢复工程师对目录二中的数据进行了拼接复原。回复实现后通过验证，大部分文件能够失常应用。 6、北亚数据恢复工程师持续对不残缺的数据局部进行提取、拼接、手动修复，最终胜利复原服务器内的所有数据，经管理员亲自对数据验证后，确认服务器下层虚拟机能够失常应用，数据残缺，本次数据恢复胜利。

NTFS文件系统是目前应用比拟宽泛的文件系统格局，NTFS文件系统提供了数据的爱护和复原性能，领有更强的安全性，基本上取代了FAT文件系统。越来越多的服务器采纳这一文件系统。上面北亚数据恢复工程师分享一下NTFS文件系统下的服务器设施因为误操作导致阵列中的分区被格式化时逆向操作复原服务器数据的办法。 1、备份数据。为了防止对原始数据造成挫伤，北亚数据恢复工程师拿到硬盘后会镜像所有原始数据。 2、剖析分区大小。在备份文件内查看数据的0-2扇区，弄清楚这台服务器的分区有多少个扇区，而后北亚数据恢复工程师依照RAID5的计算模式，用该扇区数除以服务器内理论硬盘（不包含校验盘在内）的数量，失去一个扇区数。而后间接跳转到该扇区，在这个扇区的左近能够查找到另一个GPT分区表，这样就能够查看分区的大小了。例如：6块盘的raid5阵列，如果分区大小为1048309759扇区，计算时就应该用1048309759除以5等于209661951扇区。工作界面如下图所示(GPT分区表项底层体现，标记项前8个字节为分区起始扇区，之后8个字节为分区完结扇区，单位512字节/扇区，64bit)： 3、重组raid阵列。因为raid5的安全级别绝对较高，所以很多公司在本人的服务器上应用raid5磁盘阵列。在raid5阵列下，只有剖析出raid成员盘的数量和raid走向就能够进行重组了。本案例是NTFS文件系统下的数据恢复，因而只须要找到分区的文件记录项，而后北亚数据恢复工程师会依据NTFS文件系统中的MFT程序找到raid5的条带大小和raid走向。下图为类似案例的截图。北亚数据恢复工程师依据剖析进去的RAID构造重组RAID，可能会遇到文件目录构造失落的状况，文件目录失落状况如下图所示： 小贴士：对NTFS文件系统理解的敌人们都晓得，在NTFS文件系统下从新格式化实践上是不会对数据造成太大影响，但也有可能呈现局部文件目录构造失落的状况。揭示用户不要过分依赖服务器数据恢复技术，尽管能够借助数据恢复技术对失落的服务器数据进行复原，然而随之随同肯定的危险和损失，平时肯定要定期备份，尽可能的防止服务器数据失落的状况产生。

环境： IBM存储DS3512；6块600G的sas硬盘组成raid5；liunx和windows虚拟机共24台，压缩包文件，配置文件；划分一个lun，其中lun调配给Linux服务器，共享给虚拟化应用，寄存虚拟机文件；文件系统类型OCFS2。 故障： 6块盘中的4块盘损坏导致raid5生效，数据失落。 管理员分割北亚数据恢复核心寻求帮忙。 数据恢复过程： RAID5仅反对一块硬盘损坏的冗余爱护。在有热备盘的状况下，一块磁盘掉线后，同时rebuild实现之前，不能再有任何硬盘呈现损坏。 一、北亚数据恢复工程师对6块盘以只读模式做镜像，发现4块盘有坏道，对有坏道的扇区进行屡次尝试数据读取。 二、北亚数据恢复工程师依据IBM-DS3512存储算法和文件系统底层构造，剖析raid5构造。A、北亚数据恢复工程师剖析存储6块硬盘的raid5散布状况；B、北亚数据恢复工程师对文件系统构造进行剖析，并根据数据在硬盘中的散布法则，找出RAID条带大小及RAID走向；C、北亚数据恢复工程师重组出RAID5。 三、提取LUN。A、北亚数据恢复工程师剖析数据LUN在raid中的散布状况；B、校验LUN的完整性及正确性；C、北亚数据恢复工程师编写程序提取全副数据LUN。 四、解析ocfs2文件系统。A、LUN生成实现后，对ocfs2文件系统进行解析；B、依据文件系统的构造，编写相应的程序；C、应用编写好的程序提取数据：超级块截图 目录节点截图 指针节点截图 数据库信息截图 1、元信息整顿： 北亚数据恢复工程师编写扫描程序，对lun进行扫描，读取ocfs2文件系统的节点，目录信息，并把扫描到的所有信息插入数据库。 2、数据提取： 阶段一：因为局部虚拟机的优先级别和实效性十分高，须要尽快将其复原进去，北亚数据恢复工程师依据管理员提供的文件信息列表，编写脚本，读取数据库并重构文件的目录树，针对焦急的虚拟机优先提取复原。 阶段二：遍历整个数据库，读取数据库中的全副残余文件信息，对目录树残缺的文件，重构残缺目录树。提取数据库中残余未提取的全副文件。 数据恢复后果:此次复原工作共复原近1.4T数据，24台虚拟机、压缩包和配置文件。24台虚拟机能够全副启动，虚拟机里安排的业务利用也胜利启动。经管理员验证，数据文件全副正确无误，本次复原圆满成功。

环境： 15块硬盘组成的raid5阵列；raid5阵列下层存储构造是一个xfs裸分区，起始地位是0扇区。 故障： 阵列中一块硬盘呈现故障掉线，热备盘上线同步数据的过程中又有其余硬盘掉线，导致数据同步过程中断，阵列解体，数据失落。管理员分割北亚数据恢复核心寻求帮忙。 硬盘物理故障检测： 北亚数据恢复工程师对这个阵列中的所有硬盘进行了物理故障检测，发现最先离线的硬盘发现了大量的坏道，起初同步数据过程中掉线的硬盘存在大量坏道，为了确保数据恢复的最终残缺度，对阵列中没有掉线的硬盘也逐个进行了物理故障检测，最终确定其余硬盘没有物理故障。 数据恢复过程： 这是一个十分典型的raid5磁盘阵列在进行热备盘同步数据过程中，硬盘掉线导致的raid解体案例。针对这种状况，想要复原数据最便捷的办法就是修复第二块掉线硬盘的物理故障，将硬盘内数据恢复进去，而后重组raid阵列即可。 1、北亚数据恢复工程师对所有失常硬盘进行了只读备份，把第二块掉线硬盘独自进行了备份，在这过程中跳过坏扇区，尽可能残缺的备份全副数据。因为这块硬盘中存在着坏扇区，该局部数据无奈读取，只能由北亚数据恢复工程师手动查看底层数据，依据异或法则计算坏扇区地位的数据，进行手动写入。 2、将所有硬盘内的数据都镜像实现后，北亚数据恢复工程师进行虚构riad环境重组，验证riad5构造是否正确。将镜像好的第二块掉线硬盘替换第一块硬盘，对其进行数据同步。 验证复原数据：数据同步完结后，由北亚数据恢复工程师对数据的正确性进行验证，验证无误后由管理员进行最终的数据验证，通过验证，复原进去的数据目录构造残缺，所有数据可用，程序无报错且运行失常，最终确认本次数据恢复胜利。 小贴士：在北亚数据恢复核心的各种数据恢复案例中，raid5数据恢复案例是比拟常见的复原案例。北亚数据恢复工程师发现：因为raid5阵列的冗余机制，用户过于信赖raid5阵列的安全性，疏忽了平时的保护，最终导致阵列中硬盘离线，数据失落。 Raid5磁盘阵列比其余类型的阵列的安全性绝对要高，但仍然存在数据失落的状况。在平时不要漫不经心，定期维护、及时检修、更换老旧不稳固的硬盘，能力尽可能的防止因为硬盘故障导致的数据失落。

环境：HP DL380服务器；三块300GSAS硬盘；数据库在D分区；备份放在E分区。 故障：一块硬盘呈现故障，状态灯红色，RAID瘫痪，存储故障，D分区不能辨认，E分区可辨认，拷贝备份文件报错。重启服务器，导致先离线的硬盘上线，同步一段时间数据，然而在同步实现之前就强制关机，之后就没有动过服务器。 数据恢复过程：1、为了确保现存磁盘中数据的平安，北亚数据恢复工程师先对磁盘做只读镜像备份，三块硬盘能够失常读取，没有发现坏道，只读镜像备份日志。 2、北亚数据恢复工程师对备份的镜像文件进行详细分析，重组raid构造，并进行异或校验，局部校验通过。因为离线硬盘上线之后进行同步操作可能会损坏数据，局部通过就是示意数据有损坏。 3、RAID剖析过程，尝试多种硬盘离线状态下提取数据，每块盘离线所提取的数据都是一样的。 4、北亚数据恢复工程师首先针对E分区中的dat文件进行剖析修复。发现两个备份文件都有损坏。 5、北亚数据恢复工程师剖析聚合dat碎片，验证dat数据完整性，底层构造显示有损坏。 6、同时进行D分区的数据文件的剖析扫描，因为存储同步，数据文件目录不可见。7、北亚数据恢复工程师对D分区自在空间数据页进行扫描，并对文件碎片进行剖析和聚合。8、北亚数据恢复工程师验证数据文件碎片的完整性和有效性。9、提取备份文件中的数据记录到新建的数据库中。10、通过下层利用连贯数据库，验证数据可用性，数据库文件能够失常加载，下层应用软件中用户账号失常，能够进行失常数据查问。 数据恢复后果：在本次数据恢复过程中，在E盘发现2个SealLib数据库的备份文件。然而备份文件数据中页构造有小局部损坏， 在D分区扫描的后果中数据碎片发现较间断的数据片段，碎片可用。通过对D分区碎片和E分区备份文件进行整合拼接，最终修复解析出的数据能够撑持整个利用的失常应用，下层利用能够失常查询数据库内容。

故障：数据库报错：“MSSQL Server 2000 附加数据库谬误823”，附加数据库失败。 故障剖析：数据库呈现“823”报错信息通常有以下三种起因：1、数据库的物理页面呈现了损坏。2、校验值损坏导致数据库页面无奈被辨认。3、异样断电导致的文件系统损坏，数据库页面失落。数据库呈现“823”报错信息这种状况下如果有备份，只需还原备份。然而如果没有备份，或者备份间隔时间太久，或者备份数据不可用，那么就须要进行数据恢复。 数据库数据恢复过程：1、北亚数据恢复工程师尝试附加数据库，修复数据库（下图），对数据库进行附加后会提醒“823”谬误。2、北亚数据恢复工程师应用北亚MSSQL文件检测工具对数据库进行检测。3、北亚数据恢复工程师计算并批改数据库谬误数据页的校验值。4、北亚数据恢复工程师从新附加数据库，附加数据库胜利。5、北亚数据恢复工程师应用dbcc检测数据库。6、修复上述谬误，再一次dbcc检测数据库。 数据恢复后果：咱们再次进行dbcc检测数据库后发现曾经没有任何谬误提醒，从新附加数据库，没有呈现任何报错，附加数据库胜利。通过失常的数据库环境对数据库进行查问、验证，最终能够确认所有数据被残缺复原。数据库修复胜利。

环境：vmfs 6.5底层硬盘单盘容量5T，下层vmfs文件系统，存储的数据是SqlServer数据库及其他办公文件。 故障：技术人员对虚拟化进行了还原快照操作，导致了数据库数据的失落，分割北亚数据恢复核心来复原还原快照之前的数据库文件。 数据恢复过程： 北亚数据恢复工程师在收到原始磁盘后，首先在只读环境下对硬盘进行了镜像备份，镜像进去的文件将用于数据分析及重组等操作，原始磁盘将在镜像实现后偿还客户，不进行任何操作。通过检测，所有的硬件设施都没有故障，不波及到物理修复方面的工作。镜像备份实现后，北亚数据恢复工程师依据底层数据制订了两套数据恢复计划：1、对快照文件进行修复；2、拼接数据库碎片修复数据库。 计划一、复原快照文件1、依据vmfs文件系统构造和虚拟机的底层数据，北亚数据恢复工程师编写了程序进行底层数据的扫描，提取10T虚构磁盘的元信息PBC,SBC。2、扫描到PBC，SBC信息后，尝试拼接失落的快照文件，拼接实现后进行数据验证，发现扫描提取进去的PBC，SBC损坏较多，无奈利用现有的信息进行快照文件的拼接，此计划不可行。 计划二、拼接数据库碎片1、依据vmfs索引和位图信息进行数据扫描，提取虚构磁盘的残余空间。2、北亚数据恢复工程师再次编写数据扫描程序，将残余空间内的数据库页信息进行扫描和提取。3、通过沟通，北亚数据恢复工程师确认了须要复原的数据库名称及表名，依据扫描到的数据库页信息和管理员提供的数据库名字和表名字，查找失落数据库页。4、通过查找，提取了数据库页信息，再经北亚数据恢复工程师人工进行比对，确认了须要复原的数据库信息，编写数据库拼接程序，调整相关系数，主动对扫描出的数据库碎片文件进行拼接重组，最终胜利复原数据库文件。5、通过北亚数据恢复工程师验证，数据库能够失常关上和应用，随后由管理员对数据做最终验证，通过验证确认了数据残缺可用，复原胜利。 复原后果：通过以上2种计划的尝试：其中计划一因为vmfs文件系统的元信息损坏较多，无奈拼接出快照文件。于是采纳计划二，对虚构磁盘残余空间进行扫描，获取数据库页信息，依据失落数据库名字，表名字查找相干页信息，提取并拼接数据库碎片，最终胜利复原vmfs虚拟化下的数据库。

环境： EMC Unity 400型号存储（EMC新一代中端存储，同时反对block，file和vvol三种服务类型。）；存储连贯2台硬盘柜； 2台硬盘柜上共创立2组相互独立的POOL； 2组POOL共蕴含21块6T容量的硬盘，硬盘规格为520字节硬盘。 故障： 在应用过程中误操作删除了2组POOL上的局部数据卷。管理员分割北亚数据恢复核心寻求帮忙。 故障检测： 在此之前，国内仿佛还没有过该型号存储数据恢复的胜利案例，没有任何可借鉴的教训、技术，是一个全新的数据恢复课题，须要从0开始钻研如何对这个型号的存储进行数据恢复。 通过北亚数据恢复核心研发部共事的不懈努力，终于胜利逆向解析出了EMC Unity 400存储的数据算法构造，解决了EMC Unity 400存储的数据恢复问题，挽回了数据。 1、北亚数据恢复工程师对全副硬盘进行备份，并转换为512字节格局。 2、北亚数据恢复工程师与管理员进行沟通，理解到一共删除了5个数据卷。 3、北亚数据恢复工程师对硬盘底层进行初步检测剖析，硬盘底层数据量较多，删除数据卷后，相干数据空间应该没有回收清零，数据恢复胜利的概率很大。 数据恢复过程： 1、Raid剖析重组 北亚数据恢复工程师对被删除卷波及的共21块6T硬盘进行剖析，共配置2组RAID6。其中1号RAID蕴含11块硬盘. 2号RAID蕴含10块硬盘， 依据以上信息应用专用数据恢复软件虚构重组出2组RAID，并别离导出成镜像文件。 2、全局位图整顿 北亚数据恢复工程师对每组RAID后面的全局位图信息进行读取，整顿。如图为存储的全局位图： 将整顿后的位图信息写入数据库。 整顿后的全局位图中，offset代表RAID（POOL）中的数据块块号，据此，能够大抵获取RAID（POOL）中被删除的数据卷对应的已开释的数据块。 3、自在数据块整顿 对获取到的自在数据块进行遍历扫描，找到被删除的数据卷的头部，并确认用户数据的一个索引信息，依据这个索引信息，能够索引到残缺的用户数据卷。对被删除的数据卷的头部进行读取，获取到用户数据卷的局部索引位图。同时对自在数据块持续进行遍历扫描，获取到残余的索引位图。 4、自在数据块拼接 与管理员的沟通了解到，删除的5个数据卷全副为NTFS格局的数据卷，据此，依据NTFS文件系统的构造，联合自在数据块位图和用户数据卷索引位图，北亚数据恢复工程师编写程序对自在数据块进行匹配拼接，残缺拼接还原出5个NTFS格局的数据卷。 5、文件系统修复 数据卷拼接实现后，北亚数据恢复工程师对数据卷中NTFS文件系统的正确性及完整性进行校验，修复文件系统中的谬误，手工对局部未匹配到的自在数据块进行剖析解决，拼接到相应的数据卷中。解析复原出的数据卷，将数据拷贝到指标空间中。 数据恢复后果：通过管理员的验证，被删除的5个数据卷完全恢复，数据残缺、可用。通过这次数据恢复，北亚数据恢复工程师曾经把握了EMC Unity 400存储的算法构造。EMC Unity 400存储的数据卷删除问题，甚至硬盘损坏、控制器故障等问题都能够找北亚数据恢复核心解决。

环境：windows操作系统，1.2T硬盘，NTFS，sqlserver数据库12个。 故障：硬盘误操作导致分区损坏，数据库数据失落，须要对硬盘里的数据库进行数据恢复。 数据库数据恢复过程： 一、扫描磁盘空间北亚数据恢复工程师首先应用北亚数据恢复核心自研的SqlServer数据库工具对硬盘进行全盘扫描。依据数据库的页构造，扫描磁盘空间，获取数据库页偏移地位，对象id，页号等信息。 二、拼接数据库1、Sqlserver的每个数据库页都是从0号页开始编号，客户共12个数据库，导致有大量反复页，因而无奈间接按页号从小到大拼接。2、依据客户提供的数据库名和数据记录中guid，来判断数据库页属于哪个数据库。3、依据数据库名字、页号拼接出数据库。4、因为缺失数据库页，拼接的数据库大小存在差别，须要批改数据库大小属性信息，之后进行挂载。5、挂载数据库、胜利挂载。 数据验证：数据库胜利挂载后，北亚数据恢复工程师对数据库数据进行了查看，确认复原残缺后，分割管理员亲自对SqlServer数据库记录进行完整性验证。通过验证，12个数据库实现复原，数据库记录残缺，通过评估确认数据残缺复原。

作者：郭斌斌 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景客户反馈生产环境中，MySQL 5.7 通过 xtrabackup+ Binlog 做基于工夫点的复原操作时，继续卡在 Binlog 的回放阶段，旷日持久，久到离谱。他对于这种旷日持久的操作产生了狐疑，想要确认数据库的这种行为是否正当，因而有了本文的 Binlog 回灌验证操作。 二、复现前提MySQL Version：5.7.22 Binlog format： Row 筹备 Delete 800多万记录的 Binlog 三、复现筹备3.1 创立表、结构数据 mysql> create table t1(id int primary key,name varchar(10));Query OK, 0 rows affected (0.02 sec) mysql> insert into t1 values(1,repeat('a',10));Query OK, 1 row affected (0.01 sec)mysql> insert into t1 select (select count(1) from t1)+id,name from t1;Query OK, 1 row affected (0.01 sec)Records: 1 Duplicates: 0 Warnings: 0 ………………mysql> insert into t1 select (select count(1) from t1)+id,name from t1;Query OK, 4194304 rows affected (57.75 sec)Records: 4194304 Duplicates: 0 Warnings: 03.2 筹备 Delete 800多万记录的 Binlog 文件 ...

【服务器数据恢复故障形容】客户一台Dell R720服务器，配置有一组raid5磁盘阵列，阵列由4块sas硬盘组成，每块硬盘的容量为4T。因为业务扩充，本来的阵列空间有余，客户想增加2块硬盘到服务器上，组成raid0进行空间的扩容。客户的操作方法为：增加两块硬盘到服务器上，而后再主板bios里组成一个软raid0从而实现扩容，扩容过程没有异样，但重启后服务器零碎无奈启动了，管理员应用引导盘进行挂在，查看服务器信息，发现硬盘分区信息失落，服务器上原有的数据失落。 【数据恢复过程】首先将客户的硬盘依照原有顺数进行编号并取出服务器，以只读的形式连贯到数据恢复专用服务器上进行扇区级镜像备份，随后复原原始服务器状态，在镜像文件中进行数据分析和数据恢复。依据客户形容进行判断，该服务器本来分了2个分区，别离为零碎分区和数据分区。经分析判断第一个分区的数据结构异样，跳过指定扇区后能够查看到失常数据。持续剖析raid阵列构造，最终借助数据恢复工具在数据恢复专用服务器上虚构重组出客户的原始磁盘阵列状态，导出服务器数据。 【客户数据验证】数据恢复工程师对复原的数据进行验证无误后分割客户管理员亲自对数据进行验证，最终确认复原的数据残缺、精确，本次数据恢复胜利。

[虚拟化数据恢复故障形容]须要进行数据恢复的是北京一家公司的信息管理平台，平台配置无数台VMware虚拟机，虚拟机是ESX SERVER共享一台某品牌的 DS4100存储，虚拟机内数据容量约2TB左右。虚拟机在失常工作过程中忽然提醒虚构磁盘失落，管理员发现后立即进行了查看并进行了重启操作，重启后虚拟机仍然不可用，虚构磁盘失落，服务器内数据不可用，急需进行数据恢复操作。 [虚拟化数据恢复故障剖析]工程师首先对客户的存储设备进行了只读模式下的镜像备份，防止毁坏原始故障环境。在镜像文件中对数据进行剖析发现所有数据中的无效“55AA”示意都存在，硬盘ID标记也存在，但分区表数据失落。存在一个空的ntfs卷，通过计算确定卷大小约2T，别离于卷的开始地位，约2.8G地位等地位占用了总共约120MB空间，其余地位并未占用空间。剖析服务器的vmfs卷，共剖析得出2组vmfs分区，第二组是第一组的扩大分区，第二组分区内数量较小，通过剖析确认数据次要存储在第一个分区里。重点剖析傣族vmfs得出如下论断：第一、第二级索引保留残缺，局部构造失落。 [虚拟化数据恢复过程]在数据恢复专用服务器上搭建与原始环境雷同的虚拟化环境，连贯两个vmfs分区，提取vmdk及所有配置文件，通过nfs回迁至虚拟化环境。重建卷头部信息，索引列表等地位被毁坏的信息，间接附加即可。 [虚拟化数据恢复总结]本次数据失落的次要起因是因为客户的服务器已经在Windows零碎下格式化为ntfs格局并且还从新分区，随后又对该分区进行删除。这一操作导致其余服务器接入存储后光纤环境互斥不当，虚拟机瘫痪。

【服务器硬盘黄灯简介】对于服务器来说，一旦硬盘呈现损坏，将会给企业带来极大的损失，明天将为大家介绍一下硬盘损坏后的数据恢复办法。服务器硬盘指示灯的显示：服务器闪动黄灯时是一种警示，通常为服务器硬盘存在故障行将下线的提醒。这种状况倡议及时更换好的硬盘到服务器上。须要留神的一点事服务器通常都是大量数据频繁替换工作，所以指示灯个别会疾速闪动，但如果某个硬盘只有一个黄灯亮着其余灯都没有的话，那么通常示意这块硬盘呈现故障损坏了，更换新硬盘进行同步即可。那么如果硬盘损坏没有及时发现或者更换硬盘失败导致服务器解体，咱们应该如何进行数据恢复呢？小编通过案例解说一下。 【服务器数据恢复故障形容】呈现故障的服务器为某品牌的机架式服务器，配置了7块硬盘，SAS接口，Windows操作系统，raid5磁盘阵列。服务器上有一块硬盘亮黄灯，随后被raid阵列踢出，raid阵列解体，须要进行服务器数据恢复。 【服务器数据恢复过程】第一步：工程师首先将客户服务器上的硬盘进行了排序编号，随后取出服务器，放弃服务器原始状态可还原。第二步：对所有硬盘进行故障检测，确定每个硬盘的运行状态状况。第三步：将所有运行状态失常的硬盘镜像到数据恢复平安存储池中，如果硬盘存在物理故障须要依照硬盘物理故障解决方案进行硬盘物理数据恢复，并且尽可能的将存在物理故障的硬盘内数据备份到数据恢复存储设备中。第四步：对所有的镜像文件进行底层数据分析，剖析出raid的原始构造和数据参数，同时剖析各个硬盘的离线状况。第五步：利用剖析出的raid原始构造信息在数据恢复专用服务器上重组raid数据，并且在只读环境下将重建好的raid阵列进行逻辑校验，如果发现校验无奈通过，则示意虚构重组的raid阵列不正确，须要重新组建，直到校验通过为止，生成raid的残缺镜像。第六步：对存在的文件系统问题进行手动修复，还原原始服务器阵列状况，迁徙出所有数据。 【服务器数据恢复论断】本次数据恢复历时1个工作日，100%数据恢复胜利

【用户单位】 王先生【硬盘根本状况介绍】 须要进行数据恢复的硬盘为WD（西部数据）品牌的容量为3000GB的电脑机械硬盘。硬盘本来应用在台式机上，Windows操作系统，NTFS/FAT文件系统。【硬盘故障体现】 用户开机后发现硬盘存在异样响声，电脑无奈开机，将硬盘连贯到硬盘盒上尝试辨认，硬盘仍然无奈辨认。因为硬盘内的数据非常重要，于是客户王先生分割到数据恢复核心进行数据恢复。【数据恢复故障剖析】 工程师将硬盘接入到数据恢复专用设备上进行检测，确认硬盘存在异响的起因是磁头损坏导致的。【数据恢复过程】 数据恢复工程师对硬盘进行检测，评估硬盘磁头的损坏水平，预估数据恢复成功率并与客户王先生进行了沟通。征得客户批准后工程师在无尘操作间内对故障硬盘进行了收盘更换磁头的操作。将失常磁头更换到故障硬盘中，将硬盘接入到数据恢复专用设备pc3000中，应用数据恢复设施读取硬盘内的数据并进行提取。对提取出的数据进行验证，确认数据恢复残缺、可用。客户王先生亲自对复原的数据进行验证，确认本次数据恢复胜利。【数据恢复论断】 经客户确认，本次硬盘数据复原胜利。【后记】 硬盘是数据存储介质，一旦硬盘产生故障不仅影响电脑的运行和操作，还会导致硬盘内的数据失落，造成不必要的损失。一旦硬盘产生物理故障，应该尽量少加电，防止重复通电导致硬盘盘片受伤害，影响数据恢复的残缺水平。

作者：华融科技 刘宝珍本文起源：转载自公众号-MySQL解决方案工程师* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、背景和大略的思路2020 年 2 月 25 日，微信的朋友圈大量转载微盟遭逢了零碎重大故障（36 小时内尚未复原外围生产数据）。从而想到自己在两周前解决的一个案例：开发人员误删除了生产数据，自己复原的一个过程。同时给这个故障的处理过程做一个总结，也对学过的常识做一个梳理，心愿对运维的同学们有一个警示作用。 2 月 13 日 23:00 接到微信告诉，是否帮忙复原数据。 零碎环境信息如下： 操作系统：RHEL7.5数据库：MySQL 5.7 社区版，一主两备23:05 开始染指数据失落的故障。确认一个大略解决问题的思路： 找到是什么人在什么工夫点做了什么操作？这个操作对系统的影响有多大，是否对其余零碎有影响？确认这个操作是不是失常业务体现？确认数据库里受到影响的日志的时间段在仿真环境复盘整个故障制订技术复原计划，在仿真环境验证数据恢复计划在仿真环境验证数据恢复后利用是否失常备份生产环境数据，利用数据恢复计划到生产环境生产环境绿灯测试，无误后，复原实现因为复原生产数据是重大的数据调整，须要报请领导批准，须要有齐备的数据回退计划。 二、数据恢复过程以及技术剖析用了 5 分钟理清了解决这个问题思路，接下来就是思考具体的数据恢复了。在解决这个问题过程中，有两个难点须要解决。 确认要复原的 binlog 的开始和完结。依据 binlog 的开始和完结，确认数据恢复计划，以及是否须要须要排除在这个时间段产生的其余烦扰数据。首先解决第一个问题。询问开发人员，开发人员给出晚间大略 20:20 左右操作 rest 接口，调用了 activity（以下简称工作流）平台删除流程模板的操作，导致该流程模板下所有的流程实例全副被删除，在该流程模板下有 5 个在途的流程尚未解决实现。依据开发人员的形容，登录到工作流平台的数据库，查看数据库在 20:20 左右的 binlog 文件，并对 11 号 binlog 文件进行备份。将 binlog 拷贝到一个开发的服务器，通过 mysqlbinlog 进行解析。解析命令为：mysqlbinlog -v --base64-output=decode-rows \--skip-gtids=true --start-datetime='2020-02-13 20:10:00' \--stop-datetime='2020-02-13 21:30:00' \-d {$DBNAME} mysql-bin.000011 >>aa.log dbname察看解析后的 SQL，在 20:20 分并未发现大量的删除操作，确认开发人员的话不可信，做故障诊断的第一准则：任何人的话都不能全信，也不可能不信，带着疑难来找到论据证实他的说法。持续翻看解析的 binlog，20:30 开始呈现大量的 DELETE 和 UPDATE 等操作，开始狐疑这一点是不是有问题的时间段。将这一段的 SQL 进行演绎总结，演绎须要操作几个表，对这个几个表的操作类型，以及操作的数据的类别（业务 ID）。同工作流平台的共事进行确认，删除一个工作流的模板，是不是波及到这些表的变更，工作流平台的共事确认是这个过程，数据恢复的心愿诞生了！依据以前的教训积攒，Github 上有个开源我的项目 binlog2sql，能够将 binlog 的 event 翻译成 SQL 语句，也能够翻译成反向 SQL，登时感觉这个问题应该很“容易”解决了。依据以上思考，开始在仿真环境里装置 binlog2sql 工具，该工具就是一个 Python 的程序，须要装置好 Python 环境以及须要的三方库即可，具体的应用形式请参考：https://github.com/danfengcao...，同时也再次感激工具的作者曹老师。在仿真环境里，复原生产环境有问题的实例，同时在工作流平台将利用的 JDBC 的 URL 指向新的复原好的实例。以上几个过程，曾经解决了第一个问题，接下来咱们要解决第二个问题。在以上的步骤里，曾经在仿真环境复盘了生产环境的故障，同时在也仿真环境里里装置了 binlog 转成 SQL 的工具。应用 binlog2sql 的工具，解析进去谬误执行的 SQL，让工作流的平台的同时进行确认，同时让工作流的共事，确认在这个时间段内没有其余的利用也在操作这个数据库。工作流的共事确认 SQL 全副为误操作产生的 SQL。具体的确认形式如下： ...

服务器故障状况介绍：服务操作系统：linux服务器服务器型号：某品牌X3850服务器硬盘数量/接口类型：4块 SAS接口阵列级别：raid5磁盘阵列故障状况：服务器忽然瘫痪操作状况：服务器瘫痪后原零碎进行了重新安装，须要复原的数据类型：数据库、办公文档、代码文件等 服务器故障检测：工程师对客户的服务器进行了检测，通过检测发现因为重装系统导致逻辑卷产生扭转，文件系统被毁坏，呈现空白超级快，须要对服务器内原有数据进行复原。 服务器数据恢复过程：工程师首先对服务器进行了底层数据分析，通过节点间的互相关联关系剖析出被毁坏前的节点信息，并通过数据恢复伎俩对节点进行修复。对文件系统中的文件进行调整，生成B+树并导出所有节点，对导出的节点进行排查，去除对数据恢复有效的节点，而后从新排序生成对应的地位信息。依照对应地位信息查问节点，生成树的索引信息，随后生成超级块信息。最初，数据恢复工程师在虚拟机下创立快照，将修复后的数据挂载到新创建好的快照下，能够看到文件内容，在虚拟机环境下持续对文件目录地位、名称等信息进行修改，查找文件头、文件标记地位进行修复，最终复原所有数据。 服务器数据恢复后果：通过工程师一系列数据恢复操作，胜利复原出原服务器内的数据，分割客户工程师亲自对数据的完整性、正确性进行验证，通过验证，确认复原的数据残缺、正确，本次数据恢复圆满完成。

一、故障形容因为客户方的人为误操作，将linux文件系统误装入到Ocfs2文件系统的数据卷上，导致原始Ocfs2文件系统被新格式化Ext4文件系统，据对两种文件系统格式化形式的理解，Ext4文件系统每隔几百兆会写入文件系统的原始信息的个性，用户的数据可能受到肯定水平的毁坏，但不会被毁坏太多。 二、备份数据1、将存储以只读模式映射给备份服务器。2、应用dd，Winhex等业余备份工具将映射到备份服务器中的数据做全副镜像。3、做齐全部镜像后，将所有存储配置及链路还原至初始状态，之后数据恢复操作均不对原始硬盘做任何操作 三、故障剖析1、剖析ocfs文件系统构造找到ocfs2文件系统的超级块，通过剖析超级块得出该文件系统的一些根本构造信息，而后通过客户给出的虚构磁盘文件名称，查找到虚构磁盘文件的目录项，继而找到所对应的所有一级索引项和二级索引项，并利用自主开发的文件系统解析程序，对已备份的数据进行文件系统解析。ocfs2文件系统的索引项构造如下。一级索引项二级索引项2、修复文件系统修复损坏的文件系统，对原始Ocfs2文件系统做一致性检测，并对损坏的区域进行人工修复。 四、复原数据1、生成数据利用自主开发的针对Ocfs2不残缺文件系统的解析工具对已修复的Ocfs2文件系统进行解析。并依据文件系统剖析的后果，编写对应的数据提取程序，利用程序最大水平的复原每一个虚构磁盘文件，并对复原的每一个虚构磁盘文件进行一致性检测。2、文件检测与修复对复原虚构磁盘文件进行解析，验证虚构磁盘文件是否有谬误，并尝试修复。复原其中的用户文件，对已复原的用户文件进行一致性检测，并尝试修复损坏的文件。 五、验证数据1、验证虚拟机针对用户比拟重要的虚拟机做验证，发现虚拟机大多都能够开机，能够到登陆界面。有局部虚拟机开机蓝屏或开机检测磁盘，然而进过光盘修复之后都能够启动。局部虚拟机开机如下：另外发现一台虚拟机磁盘文件复原之后，通过解析发现该虚拟机中没有数据，持续对该虚构磁盘文件进行剖析，发现该文件索引项存在，然而索引构造并不多，数据量也很少，有可能存在认为清零或批改的状况，也可能虚拟机本来就没有多少数据。2、验证数据库针对重点虚拟机中的数据库做验证，发现数据库都失常。局部数据库可能与应用程序对接有的肯定问题，经客户分割应用程序原厂的工作人员，通过修复之后，数据库都能够失常应用。 六、移交数据因为工夫紧迫，先应用业余工具“UFS”顺次导出ocfs2中的虚拟机。而后安顿工程师将R510服务器上的虚构磁盘数据带到客户现场。在现场应用网线将R510服务器接入到客户外部的网络当中，而后通过NFS共享，将虚拟机磁盘文件上传到客户的服务器上，而后通过ovm虚拟机管理工具进行虚拟机挂载。因为虚拟机数量不是很多，大小也不是很大，比拟快的实现了数据移交。 七、数据恢复总结整个数据恢复的过程中，对ocfs2文件构造的剖析占用了比拟多的工夫，依据ext4文件系统格式化的个性，Ext4文件系统每隔几百兆会写入文件系统的原始信息，对客户数据造成了肯定的毁坏，然而这个毁坏还是在可承受范畴内的，数据恢复实现后客户也认可了咱们的复原成绩。整个复原的过程因用户比拟紧急，我司也安顿工程师加班加点在最短的工夫内将数据恢复进去。在后续的数据迁徙过程中也是由我工程师和用户方工程师配合实现的。

作者：姚远专一于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。当初鼎甲科技任参谋，为共事和客户提供数据库培训和技术支持服务。本文起源：原创投稿*爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。故障形容MySQL 数据库服务器的 CPU 和主板都换了，从新开机，发现 MySQL 无奈启动！！！ 提醒：Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint .... and ...故障剖析这个问题呈现在 MySQL 5.7 之后的版本，次要的起因是 MySQL 会在最新的 checkpoint 实现后都会在 redo log 写一个一字节的 MLOG_CHECKPOINT 标记，用来标记在此之前的 redo 都已 checkpoint 实现。如果处于任何起因没有找到这个标记，那么整个 redo log 文件都会被疏忽。呈现这个谬误的话，最好是有备份进行复原，如果没有做好备份，那只能采取非常规的启动形式，但可能造成数据失落。 故障解决移除以后应用的 redo log 文件，而后能够试着启动数据库，后果启动失败！ 提醒：[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.这样的谬误，这是因为 MySQL writer 线程依照配置的工夫距离以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候，新写入磁盘的 page 蕴含了较新的 LSN，此时零碎 system 表空间头的 LSN 并没有同步更新，通常这是检查点线程的工作。在失常的解体复原中，MySQL 能够借助 redo log 来进行前滚和回滚，然而此时 redo log 曾经被咱们删掉了，MySQL 无奈进行复原操作。此时，咱们设置 innodb_force_recovery=3 来强制启动 MySQL，依然启动不胜利，改成 4 后启动了！再应用 mysqldump 导出备份，后果噩梦又来临了！MySQL 又 crash 了。 ...