beiya123的博客

硬盘所有的工作流程都与BIOS芯片的程序有关，BIOS芯片内的数据读取次数非常频繁，因此硬盘通电或者断电时就会有导致BIOS程序丢失或者紊乱的可能性。这里的电路板接口通常指数据接口，硬盘的数据接口类型有IDE、SATA、SCSI、SAS、FC等。硬盘的电源线有4个接线柱，其中红色线电压+5V，黄色线电压+12V，两个黑色的为地线，通过线性电源变换电路，变换为硬盘正常共工作的各种电压。电路板的电机驱动芯片主要用于驱动硬盘的主轴电机转动，以此来带动硬盘高速旋转，使硬盘能够快速的读取数据。2、电路板接口故障。

5、服务器的节点分布在不同的数据块内组成节点组。3、经过分析，这组raid5阵列中每个数据块大小为8扇区，每个数据块后有一个附加的数据块描述信息，大小为64字节。4、分析aggr盘序。由于阵列中的数据块大小为8扇区，根据每块磁盘的8号扇区进行分析，确定每块硬盘各自归属的组，再还原硬盘在各自的组内的排序。10、根据分析到的raid阵列信息重组raid5阵列，北亚企安数据恢复工程师编写小程序提取服务器内的数据。需要恢复误删除的数据。7、解析节点中节点类型，逻辑块号，文件数量，文件大小，所占块数量，及数据指针。

2、基于镜像文件分析所有硬盘的底层数据，分析盘序、校验方式等重构raid5阵列所需信息，利用这些信息虚拟重组raid5阵列，并对重组的阵列进行校验。北亚企安数据恢复工程师在提取的碎片文件中成功重组出原服务器所有数据，并通过验证。经管理员验证，确认所有恢复出来的数据均可正常加载，上层应用软件数据正常，本次数据恢复工作完成。3、验证重组的阵列数据，并依次将每一块硬盘设置为离线状态并尝试提取raid阵列的数据，但是发现提取出来的数据完全一致。服务器上1块硬盘的状态灯变为红色，磁盘阵列出现故障，分区无法识别。

掉线的2块硬盘存在大量坏道，无法通过常规方式镜像。服务器崩溃，经过初步检测，发现raid5阵列的两块硬盘掉线。这2块硬盘经过初步检测，硬件工程师推断掉线的2块硬盘存在物理故障，导致服务器数据丢失。需要修复存在物理故障的硬盘，然后再重组raid，从而恢复服务器数据。获取到2块离线硬盘的离线顺序，剔除较早离线的硬盘。3、根据用户方提供的信息，北亚企安数据恢复工程师验证恢复出来的数据。4、在北亚企安数据恢复工程师的协助下，将恢复出来的服务器数据回迁到用户方新搭建好的服务器环境中，本次服务器数据恢复工作完成。

1、将故障存储中所有硬盘做好标记后取出，以只读方式进行全盘镜像（包括2块故障硬盘），在镜像过程中观察硬盘状态。5、将卷里的文件拷贝出来，通过网络共享的方式验证恢复出来的虚拟机，虚拟机都可以正常启动。硬件工程师对16块硬盘做硬件故障检测，经过检测发现raid5阵列中2块硬盘存在坏道、SMART的错误冗余级别已经超过阈值。通过对日志信息的分析搞清楚两块硬盘的掉线时间，使用数据较新的硬盘来恢复数据。2、基于镜像文件分析所有硬盘的底层数据，获取重组raid所需的raid相关信息。利用这些信息虚拟重组RAID。

7、获取到数据库数据后在数据恢复专用服务器内搭建数据库环境，创建数据库、用户、分配表空间等。数据恢复工程师借助expdp/exp工具尝试对导出数据库，但这两个工具导出数据库时依然有报错，数据库已经不可能进行修复。5、数据恢复工程师再次执行恢复命令，打开数据库，查询实例状态有无报错。4、经过修复发现，由于归档日志不连续，恢复数据库所需时间段的归档日志缺失，只能使用cancel参数进行不完全数据恢复。3、根据数据库的报错情况，数据恢复工程师试图借助在线日志恢复数据，使用recover database命令。

北亚企安数据恢复工程师到达现场后，将故障服务器中所有硬盘以只读方式进行完整镜像。镜像完成后将所有硬盘按照原样还原到原服务器中，后续的数据分析和数据恢复操作基于镜像文件进行，避免对原始磁盘数据造成二次破坏。发现服务器内丢失的数据是数据库文件，导致数据库报错。通过扫描分区，然后根据文件号拼接出格式化的磁盘中的数据文件，底层解析这些数据文件，插入到数据库中，数据完全恢复。由于管理员误操作不小心删除了该分区，数据库报错，无法使用。4、解析system和拼接成的数据文件，将test01用户到数据库中。

1、将故障服务器中所有硬盘做好标记后取出，以只读方式将所有硬盘进行扇区级别完整镜像，镜像后发现后离线的硬盘有10-20个坏扇区，其余磁盘，均无坏道。5、确定备份包安全的情况下，经用户方同意后，对原盘重建RAID（重建时已经用全新硬盘更换发现坏扇区的硬盘）。8、虽然节点中描述的uid还正常存在，但属性、大小、最初的分配块全部是错误的。使用SystemRescueCd重启后检查，发现此文件时间，权限，大小均有明显错误，显然节点损坏。7、重新分析重组数据中的根分区，定位出错的目录，发现问题是由硬盘坏道引起的。

mdb_catalog.wt文件是专门用于存储MongoDB中所有集合元数据的文件，MongoDB数据库启动时必须读取的相关信息都存储于_mdb_catalog.wt文件中。1、扫描MongoDB数据库所在分区的底层数据，但是没有扫描到和_mdb_catalog.wt文件有关的信息，使用其他扫描方式进行扫描，仍然无法查找到_mdb_catalog.wt文件相关信息，基本上可以确定该文件已被覆盖，无法通过恢复_mdb_catalog.wt文件的方式来修复数据库。结果发现拷贝过去的数据无法使用。

6、结合SQL Server数据库备份修复SQL Server数据库中加密的页。通过SQL Server数据库管理工具附加修改好的SQL Server数据库，并进行查询验证。经过上面的分析，我们知道SQL Server数据库与SQL Server数据库备份加密方式一样，每128K进行一次加密，加密大小为128字节。4、打开SQL Server数据库备份，发现也是每128K进行一次加密，加密大小也为128字节。2、打开被加密的SQL Server数据库，北亚企安数据恢复工程师发现数据库的头部已被破坏。

1、将故障服务器上所有硬盘标记后取出，经过硬件工程师没有发现有硬盘存在物理故障。2、服务器数据恢复工程师基于镜像文件分析raid结构，通过分析获取到故障服务器的上raid5阵列的盘序、校验方式、数据块大小等重组阵列所必需的相关信息。根据获取到的信息重组raid5阵列。4、用户方对恢复出来的数据进行验证，经过验证，用户方确定原服务器上的数据完整无误。3、对重组完成的raid阵列进行逻辑校验，通过逻辑校验后，查看所有参数正确无误。5、将恢复出来的数据移交给用户方那个准备好的新服务器内，本次数据恢复工作完成。

通过LVM扩容的方式将sdc1分区加入到了root_lv中，剩下的sdc2分区格式化为XFS文件系统。1、将故障服务器上所有磁盘编号后取出，以只读方式将所有磁盘进行完整镜像，镜像完成后将所有磁盘按照原样还原到原服务器。2、基于镜像文件分析所有磁盘底层数据，查找服务器raid磁盘阵列的硬盘顺序、条带大小等重组raid所需要的相关信息。校验xfs文件系统的完整性及正确性，经过校验没有发现文件系统存在异常。6、修复完成后，北亚企安数据恢复工程师编写程序解析xfs文件系统，提取其中的数据。

通过用户方提供的虚拟磁盘文件名称，查找到虚拟磁盘文件的目录项，继续找到所有对应的一级索引项和二级索引项。利用北亚企安自主开发的文件系统解析程序，对已备份的数据进行文件系统解析。4、使用北亚企安自主开发的专门针对Ocfs2不完整文件系统的解析工具解析已修复好的Ocfs2文件系统。根据文件系统分析的结果，北亚企安数据恢复工程师编写提取程序恢复每一个虚拟磁盘文件，并对每一个恢复出来的虚拟磁盘文件进行一致性检测。恢复其中的用户文件，对已恢复的用户文件进行一致性检测，并尝试修复损坏的文件。

oracle数据库误执行truncate命令导致数据丢失是一种常见情况。通常情况下，oracle数据库误操作删除数据只需要通过备份恢复数据即可。也会碰到一些特殊情况，例如数据库备份无法使用或者还原报错等。下面和大家分享一例oracle数据库误执行truncate命令导致数据丢失的数据库数据恢复过程。

1、北亚企安数据恢复工程师收到快递过来的服务器硬盘后，将所有硬盘挂接数据恢复服务器上，以只读模式将故障服务器上所有数据镜像。2、基于镜像文件扫描底层数据，分析服务器数据被破坏情况，逐条排查被破坏的数据部分。同时也发现部分数据的数据区索引被破坏，需要拼接组合服务器自由空间中的文件碎片来恢复数据。根据文件结构定位到底层存储空间的位置再次进行扫描，提取符合条件的目录结构。管理员重启服务器后进行检测，发现服务器上部分文件丢失。验证无误后由用户方亲自验证数据，用户方经过验证确认数据无误，本次数据恢复工作完成。

在恢复数据的过程中，通过对镜像数据进行逐块扫描与逻辑重组，力求还原出丢失的数据节点信息。2、虽然成功恢复部分用户数据，但受逻辑卷底层数据损坏的限制，部分数据存在缺失和逻辑紊乱的情况。1、根目录丢失：由于数据复写，导致根目录被修改，存在交叉的目录索引表及重复的节点结构，无法根据目录结构解析出需要的数据节点。3、北亚企安数据恢复工程师编写脚本程序，遍历每个LUN的底层数据，生成逻辑卷的映射关系表，并梳理卷组信息。4、通过逻辑卷映射关系表，结合用户方提供的逻辑卷名称，重构丢失的两个逻辑卷。

SQL server数据库数据故障：SQL server数据库被加密，无法使用。数据库MDF、LDF、log日志文件名字被篡改。数据库备份被加密，文件名字被篡改。

由于该MongoDB数据库中存在Gridfs存储的大字段（文件）集合，所以可以通过查询集合中的记录确定记录类型，从而确定fs.files和fs.chunks集合的位置。在MongoDB数据库服务没有关闭的情况下拷贝MongoDB数据库文件，通常会导致mongod.lock文件以及WiredTiger.lock文件拷贝出错。此文件丢失会导致数据库无法获取数据库中集合对应的WT table名字、集合的创建选项、集合的索引信息等元。b、使用编译完成的wt工具，清洗回写MongoDB数据库的集合文件中的数据。

NTFS文件系统下格式化在理论上不会对数据造成太大影响，但有可能造成部分文件目录结构丢失的情况。下面介绍一个人为误操作导致服务器磁盘阵列中的NTFS文件系统分区被格式化后的服务器数据恢复案例。

服务器常见故障：硬件故障：磁盘损坏、电池故障等。软件问题：操作系统崩溃、未知的程序运行错误等。病毒破坏：勒索病毒加密、删除服务器数据等。不可控力量；服务器浸水、火烧、机房倒塌等导致服务器损坏和数据丢失。误操作：工作人员操作失误导致数据丢失，如格式化、删除、覆盖等。

基于镜像文件分析底层数据，在存储日志发现2块硬盘的报警提示，这与物理故障检测结果吻合。数据恢复工程师通过分析底层数据确定两块离线硬盘的离线顺序，将先离线的硬盘剔除。数据同步完成后，数据恢复工程师检查上层数据情况并进行数据完整性验证。硬件工程师针对存在物理故障的两块硬盘进行物理修复，然后通过专业数据恢复工具进行完整镜像备份。磁盘阵列中有2块硬盘出现故障离线，服务器崩溃，上层数据丢失。硬件工程师对客户服务器内的所有硬盘进行物理故障检测，最终确认这2块硬盘存在坏道，这是导致两块硬盘离线的原因。

某公司一台服务器，服务器上有一组由8块硬盘组建的raid5磁盘阵列。磁盘阵列中2块硬盘的指示灯显示异常，其他硬盘指示灯显示正常。上层应用不可用。

一台服务器中有一组由16块SAS接口的硬盘组建的raid5阵列。服务器磁盘阵列中有2块硬盘离线，服务器上跑的应用崩溃。经过后续的分析发现丢失的数据为虚拟机文件，包含4个卷的数据。

SQL Server数据库附加数据库过程中比较常见的报错是“错误 823”，附加数据库失败。如果数据库有备份则只需还原备份即可。但是如果没有备份，备份时间太久，或者其他原因导致备份不可用，那么就需要通过专业手段对数据库进行数据恢复。

本地服务器，安装的windows server操作系统。操作系统上部署MySQL单实例，引擎类型为innodb，表空间类型为独立表空间。该MySQL数据库没有备份，未开启binlog。人为误操作，在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除，删除后未对该表进行任何操作。

作为文档数据库，MongoDB不限制用户存储数据的体量和类型，因此适合大数据的应用环境，这对基于云的服务将特别有利。基于水平可扩展能力，以及与云服务的敏捷性结合，MongoDB数据库不但能够减少开发者的工作量，简化业务与项目的扩展流程，还能够提供高可用性和数据的快速恢复。北亚企安数据恢复工程师通过用户方的描述，以及对数据库环境和底层数据的检查，发现MongoDB数据库在迁移过程中丢失了_mdb_catalog.wt文件，所以导致数据库报错。4、创建一个全新的MongoDB数据库，并创建相应数据量的集合。

某ECS网站服务器，linux操作系统+mysql数据库。mysql数据库采用innodb作为默认存储引擎。在执行数据库版本更新测试时，操作人员误误将在本来应该在测试库执行的sql脚本在生产库上执行，导致生产库上部分表被truncate，还有部分表中少量数据被delete。

服务器数据恢复环境&故障：一台zfs文件系统的服务器，管理员误操作删除了服务器上的数据。

EMC Unity 400存储连接了2台硬盘柜。2台硬盘柜上一共有21块硬盘（520字节）。21块盘组建了2组RAID6：一组有11块硬盘，一组有10块硬盘。在存储运行过程中，管理员误操作删除了 2组POOL上的部分数据卷。

一台服务器上的8块硬盘组建了一组raid5磁盘阵列。上层安装windows server操作系统，部署了oracle数据库。raid5阵列中有2块硬盘的硬盘指示灯显示异常报警。服务器操作系统无法启动，ORACLE数据库也无法启动。

异常断电导致vSAN存储上层虚拟机无法启动。

4、通过分析thin-lvm结构获取&解读lvm配置信息。根据获取到的lvm相关信息重组lvm结构，获取和thin-pool相关的meta-lv和data-lv并校验相关性。经过校验，发现获取到的meta-lv和data-lv完整且正确。5、通过分析meta-lv获取&解读meta-lv中的原信息，从而获取到完整的thin-lv信息。6、获取到所有thin-lv信息后校检文件系统的完整性和正确性，经过校验没有发现问题。3、通过底层数据的分析获取到重组磁盘阵列的必需信息，根据这些信息重组raid6磁盘阵列。

服务器硬盘指示灯闪烁黄灯是一种警示，意味着服务器硬盘出现故障即将下线。发现这种情况建议及时更换硬盘。一旦服务器上有大量数据频繁读写，硬盘指示灯会快速闪烁。服务器上某个硬盘的指示灯只有黄灯亮着，而其他颜色的灯没有亮的话，通常表示这块硬盘出现故障，这时候更换新硬盘同步数据即可。如果没有及时发现硬盘损坏或者更换硬盘失败导致服务器崩溃，应该如何恢复数据呢？下面通过一个真实案例讲解一下服务器硬盘指示灯亮黄色的数据恢复案例。

一台配有32块硬盘的服务器在运行过程中突然崩溃不可用。经过初步检测，基本上确定服务器硬件不存在物理故障。管理员重启服务器后问题依旧。需要恢复该服务器中的数据。

华为OceanStor T系列某型号存储中有一组由24块机械硬盘组建的一组RAID5阵列。运行过程中该存储设备RAID5阵列上多块硬盘出现故障离线，阵列失效，存储中数据无法访问。

硬盘故障：硬盘存在物理坏道。硬盘存在物理坏道的典型表现：1、若硬盘为系统盘，故障表现通常为：操作系统异常缓慢、蓝屏，重启系统后引导失败并报告硬盘读取出错、系统自动反复重启。2、若硬盘为移动硬盘，故障表现通常为：电脑无法加载盘符、提示硬盘需要格式化、频繁提示需要运行chkdsk来检查和修复磁盘、数据读取缓慢、死机。

硬盘故障：硬盘固件区损坏。硬盘固件区损坏的故障表现：1、硬盘寻道正常但无法正确识别自身型号或容量。2、硬盘可以正常识别自身型号和容量但无法读取。

UNIX系统常见故障表现：1、存储结构出错；2、数据删除；3、文件系统格式化；4、其他原因数据丢失。

2、基于镜像文件分析硬盘底层数据。6、由于故障硬盘损坏严重，无法修复，且部分硬盘存在坏道，导致raid结构存在缺陷，部分文件损坏。将故障RAID5阵列中的两块离线硬盘标记后取出进行检测，发现先离线硬盘无法识别，初步推断该盘存在硬件故障，需要开盘修复，另一块硬盘可以正常识别。两组分别由4块SAS接口硬盘组建的raid5阵列，两组raid5阵列划分LUN并由LVM管理，格式化为EXT3文件系统。4、LVM重组完成之后，使用北亚企安自主开发的工具解析LV（逻辑卷）中的EXT3文件系统，恢复并导出其中的全部数据。

Oracle数据库常见故障表现：1、ORACLE数据库无法启动或无法正常工作。2、ORACLE ASM存储破坏。3、ORACLE数据文件丢失。4、ORACLE数据文件部分损坏。5、ORACLE DUMP文件损坏。