beiya123的博客

某单位依托某品牌服务器部署FreeNAS搭建iSCSI存储，以软件方案模拟FC SAN存储架构；搭配两台某品牌服务器搭建ESXi5.0虚拟化平台，通过iSCSI协议挂载远端存储空间。底层存储采用UFS2文件系统，在分区内创建大容量稀疏模式镜像文件，将该文件作为LUN挂载至ESXi虚拟化集群。集群内共计运行5台虚拟机，其中3台承载核心业务：Windows Server虚拟机：搭建本地门户网站，采用ASP.NET+PHP混合开发架构，搭载SQL Server、MySQL双数据库，是企业对外展示与业务引流核心

故障业务服务器搭载Windows Server 操作系统，部署MongoDB数据库承载日常业务数据。管理员未提前停止MongoDB运行服务，直接拷贝数据库原始文件至其他分区备份；拷贝完成后格式化原有数据库分区，再将备份文件迁回原分区，重启mongod服务后数据库启动失败，业务彻底中断。

北亚数据恢复工程师区分inode归属文件，清理无效冲突节点，再次执行只读检测，报错数量大幅减少。北亚数据恢复工程师使用SystemRescueCd重新引导服务器进行核查，发现/sbin/pidof文件的访问权限、时间戳、文件大小均出现异常，判定对应inode节点损坏，故障根源为2号硬盘坏扇区。北亚数据恢复工程师通过镜像文件分析阵列参数，最终确认有效RAID组合：盘序0、1、2、3，缺失离线的3号盘；按照确定的阵列结构，将虚拟RAID完整数据导出至独立硬盘，挂载文件系统未出现显著报错，基础数据读取正常。

GFS2是面向Linux集群的共享文件系统，支持多节点并发访问同一共享存储，广泛应用于虚拟化集群、业务集群、集中式文件存储场景。文件系统由inode节点、目录索引、哈希目录叶块、资源组位图、日志元数据等组件构成。一旦发生逻辑故障导致文件系统无法挂载，可通过底层元数据扫描、inode关联分析、目录树重构等方式尝试抢救数据。本文结合真实故障案例，完整阐述GFS2文件系统的数据恢复实施流程。

今天和大家分享一则RAID磁盘阵列真实数据恢复案例，完整还原阵列分析、镜像备份、虚拟重组全过程。

条件允许尽快备份数据；数据恢复工程师初步检测发现硬盘表面标签已被撕开，电路板BIOS周边存在焊接痕迹，确认硬盘此前做过开盘恢复，但并未成功。北亚数据恢复工程师针对盘片损伤进行专业清洁处理，调整读取策略，使硬盘能够正常识别，耗时3天完成全盘镜像，最终完整恢复全部数据。后续硬盘异响频发、读写速度急剧下降，一份100MB文件拷贝耗时长达二十分钟，直至硬盘彻底无法识别，客户才寻求专业数据恢复服务。客观来说，盘片划伤后能够完整恢复数据存在一定偶然性，但成熟的硬件处理技术、丰富的开盘实操经验，是提升恢复成功率的关键。

北京某单位业务服务器正常运行时突发宕机，运维人员排查后发现单块硬盘离线。运维人员计划更换故障盘完成阵列重建，更换新硬盘启动同步流程期间，阵列内第二块硬盘突发离线，阵列直接失效，逻辑卷无法挂载。登录存储管理界面确认两块硬盘均处于故障脱机状态，业务全面中断。

客户业务存储采用EVA企业级虚拟化存储架构，整套设备由1台主控制器、3台磁盘扩展柜、28块FC硬盘组成。设备运行期间先后出现两块硬盘离线，直接引发存储层异常：部分LUN无法挂载访问，另有多组LUN元数据丢失，整套存储服务不可用，上层业务全部中断。北亚数据恢复中心接收故障设备后，先对全部硬盘开展硬件检测，无磁头、盘片损坏等物理故障；再通过专业坏道检测工具全盘扫描，磁盘无坏道记录，可排除硬件介质损坏问题。

客户运维操作失误，误删除存储内1块5TB容量LUN与10块1TB容量LUN，业务数据全部无法访问，存在紧急数据恢复需求。

NetApp FAS3220是面向NAS、SAN混合场景打造的中端存储阵列，适配虚拟化平台、私有云及传统业务架构，可承载数TB至2PB以上存储容量需求，原生搭载数据保护、弹性扩容、自动精简配置、精简克隆、备份与容灾等全套存储特性。为杜绝恢复操作对原始物理磁盘产生二次覆盖、损坏，北亚数据恢复工程师优先对全部硬盘制作只读完整镜像，后续所有存储结构解析、数据提取操作均基于镜像文件开展，全程不触碰原始磁盘介质。提取存储目录项记录，依托目录内存储的节点编号，反向匹配对应业务文件节点，建立目录与文件的完整对应关系。

机房运维人员依照运维规范开展机房定期巡检维护工作，操作过程中出现人为失误，致使一台搭载RAID5磁盘阵列的品牌服务器出现分区丢失故障。丢失分区承载企业全部生产业务核心数据，故障发生后企业生产业务全面中断。

NTFS是当下主流商用文件系统，相较于老旧FAT系列，它具备完善的数据保护、故障恢复机制与更高权限安全管控能力，现已成为企业服务器的标准文件系统格式。不少企业业务服务器均采用NTFS部署分区。从底层原理来讲，仅对NTFS分区执行快速格式化，不会彻底清除磁盘内原始业务数据，但操作后极易损坏分区目录索引，造成文件目录结构丢失。北亚数据恢复工程师将通过本文详细讲解：RAID5阵列内NTFS分区因人为误格式化，如何通过底层逆向分析完整恢复服务器数据。

二次修复文件系统，补全缺失注册与配置文件，重新启动后SAP登录、权限、业务功能全部恢复正常。交由客户现场技术人员核验：分别启动Oracle数据库与SAP业务系统，通过SAP客户端逐项核对全量业务数据，所有台账、表单、配置信息完整无缺失，系统可稳定正常运行。数据库文件恢复完成后，业务SAP系统仍无法正常运行，判定除数据库外，SAP系统关键配置、业务资源文件同步丢失，需执行第二套恢复方案。针对存在坏块损坏的数据库文件，全域扫描磁盘数据库碎片，重组有效数据页，人工补全损坏区块，修复完整数据库文件；

北亚数据恢复工程师解析提取的数据页时发现系统表损坏，无法读取表结构元数据。搭建独立恢复环境，新建空白数据库，通过北亚数据恢复中心自研解析工具读取分区内提取的数据页原始记录，批量写入恢复数据库。初检结论：数据库文件已彻底丢失，依托文件系统恢复手段无法找回数据，需采用底层数据页提取方案开展深度恢复。原始数据库文件丢失、文件系统恢复失效，确定采用底层扫描SQL数据页、解析提取页面业务记录的恢复思路。批量解析数据表结构脚本，将字段名称、类型、长度、约束等信息统一入库存储，为后续数据页匹配提供参照。

伴随服务器硬件技术持续迭代，不同机型遭遇RAID5阵列故障时，对应的排查、修复手段存在明显差异。当前承载大型业务系统的网络架构多采用C/S或B/S模式，核心机房需部署搭载大型数据库的中心服务器。为保障设备运行安全与数据存储可靠性，行业普遍通过RAID廉价磁盘冗余阵列实现磁盘数据备份。

在服务器运维场景中，RAID5阵列双盘离线是十分常见的故障类型。RAID5本身具备单盘故障冗余能力，仅一块硬盘离线时，阵列可正常工作；一旦出现两块及以上硬盘离线，阵列便会彻底瘫痪，无法自行恢复。北亚数据恢复工程师提示：多数硬盘临时掉线，并非硬件严重损坏，而是电源波动、控制器程序异常等因素引发。但盲目强制离线硬盘上线存在极高风险：操作失误会造成阵列数据不可逆损坏。若后续再对异常文件系统进行修复，会加剧多块硬盘间的数据错乱，大幅提升数据恢复难度。

RAID磁盘阵列可为服务器搭建安全、可靠且具备扩展性的外置存储空间。但多数服务器使用者对RAID技术了解有限，加之各类产品宣传过度侧重其容错能力，让不少用户形成了RAID不会发生故障的错误认知。在日常运维中，人们常常忽视RAID阵列潜藏的运行风险，既不重视数据备份工作，也未制定完善的故障应急预案。一旦阵列突发故障，极易给企业造成严重损失。结合实际运维场景，RAID阵列故障主要诱因分为三类：RAID控制器损坏、意外断电引发阵列信息异常、RAID5阵列单块硬盘故障后未及时更换，继而出现第二块硬盘损坏，最终导致

受坏道影响，文件系统关键信息缺失，需等待6号盘镜像完成后，依托条带异或（XOR）运算，结合EXT3文件系统结构，北亚数据恢复工程师人工修复受损数据。北亚数据恢复工程师对镜像文件深度分析后发现，阵列内1号、10号、13号硬盘存在大量无规律坏道，直接损毁了EXT3文件系统的核心元数据，无法依靠镜像文件直接恢复数据。将全部硬盘接入Windows操作环境，统一设置为脱机状态，并完成所有硬盘的扇区级完整镜像，生成镜像文件，规避原始数据二次损坏风险。完成数据提取后，对dmp文件进行导入校验，数据库运行状态正常。

Oracle数据库常见故障：1、Oracle数据库无法启动、运行异常。2、ASM存储损坏故障。3、误操作导致数据文件丢失。4、数据文件与Dump文件损坏。

一、服务器故障概况本次案例为型号DS5300企业存储设备的数据恢复工作，设备外接扩展柜，底层由十余块物理硬盘划分组建多组RAID5磁盘阵列。设备日常承载业务数据存储业务，运维期间突发异常，其中一组RAID5阵列无故崩溃，阵列内数据无法正常访问。委托北亚数据恢复中心恢复故障存储上的数据。

本次故障设备为网站服务器，整机搭载6块硬盘，设备运行Linux系统，分区采用EXT3文件系统。服务器正常运行期间，单块硬盘突发异常离线。因设备组建为RAID5磁盘阵列架构，单盘掉线不会直接中断业务，服务器仍可维持正常运转。后续阵列内第二块硬盘相继离线，阵列容错机制失效，服务器直接宕机崩溃，业务全面中断。

硬盘作为存储数据的核心硬件，长期使用难免会出现各类故障，硬盘坏道就是日常最普遍、最容易引发数据丢失的问题。硬盘出现坏道，一部分是硬件本身质量老化导致，更多则是日常使用不当、缺乏保养造成。硬盘坏道主要分为逻辑坏道和物理坏道：逻辑坏道属于软性故障，大多由操作失误、软件异常、非法断电引起，通过专业软件即可修复；物理坏道是硬盘盘面、磁道出现实质性物理损伤，无法彻底修复，只能屏蔽损坏扇区防止坏道继续扩散。

2、对另一块未开盘的硬盘进行检测和开盘，开盘后发现该硬盘的磁头损坏，在盘片上检测到极微小的划痕。可以通过更换磁头、盘片处理等方式恢复数据，经过北亚企安数据恢复工程师的一番努力，终于将损坏的硬盘数据完整提取。1、检测已经开过盘的硬盘，发现硬盘盘面有规则的同心圆状划痕，属于典型的磁头故障导致盘片划伤，数据无法恢复。3、服务器数据恢复工程师收集了故障服务器存储上的日志信息，根据获取到的相关信息虚拟重组raid。4、通过位图信息在虚拟重组出来的raid中提取lun信息，导出数据并进行验证。

服务器管理员在修复和检查过程中还写入了一部分的新数据到服务器，导致损坏的目录项没有被成功修复，而是以节点号命名后存放到了lost+found文件夹内，对应的数据区索引也被自动清除。4、根据文件系统的结构信息，在底层空间的相对应位置扫描&提取符合丢失目录结构条件的信息，再与目录项节点号整合，将扫描到的目录项节点号记录到数据库。北亚企安服务器数据恢复工程师提取出lost+found文件夹下的文件名称，根据丢失文件的文件目录项节点号进行匹配，分析出丢失的目录结构。某品牌服务器+存储，安装的linux操作系统。

数据同步尚未完成时，同一阵列中的另一块硬盘掉线，热备盘同步失败，这组raid5阵列不可用，lvm结构被损坏，文件系统也无法正常使用。3、基于镜像文件对底层数据进行分析，结合EXT3文件系统结构分析raid5阵列的盘序、条带、校验方向等重组阵列的必要信息。4、重组完成后，分析raid5阵列的底层数据，找到与数据恢复有关的lvm结构信息。5、按照数据恢复方案，重组lvm以后，服务器数据恢复工程师继续分析逻辑卷内的EXT3文件系统，分析并导出所有数据。6、经过用户方验证，绝大部分数据已经恢复，认可数据恢复结果。

2、基于镜像文件分析所有硬盘底层数据，根据获取到的raid信息重组了raid，并进行抑或校验，只有部分数据校验通过。服务器数据恢复工程师通过多种方式进行尝试，但提取到的数据都是损坏的，只能修复数据。不明原因的故障导致服务器操作系统崩溃或者服务器中的数据不可用时，不建议在原服务器设备上进行数据分析和数据恢复尝试。服务器管理员重启服务器，故障硬盘重新上线同步数据，数据同步到将近一半时，管理员将服务器强制关机。服务器中有一块硬盘由于未知原因离线，服务器崩溃，存储重要数据的D分区无法识别。

前2GB被覆盖的数据已经无法恢复，且文件系统前面对整个树的索引全部丢失，加上reiserfs的树的抽象设计，重搭建树会很困难。服务器管理员重装系统后发现数据组织结构发生了改变：2GB的boot与swap分区+数百GB的LVM卷，LVM卷中文件系统位置有个空的reiserfs超级块。需要恢复的数据是LVM卷中的reiserfs文件系统上所有用户数据，包含数据库、网站程序与网页、OA系统里的所有办公文档。5、在修复用的suse虚拟机下，挂载用于copy数据的目标硬盘，mkfs后将所有数据cp到目标盘。

初始化完毕后，开始提取文件的各级MAP。再使用块号取余块数，得到数据块在此磁盘上的物理块号，物理块号乘以块大小，得到数据块偏移位置。一般情况下存储划分出的单个节点会作为LUN映射到服务器使用，根据file_size可以确定这个文件的大小，按照文件大小分组后再选取usn最大值的节点，跳转到MBFI文件的offset值偏移位置，取出节点。2、服务器数据恢复工程师基于镜像文件分析所有硬盘底层数据，找到盘头位置的超级块，继续分析超级块信息得到磁盘组的起始块信息、磁盘组名称、逻辑组起始块号、raid编号等基本信息。

3、北亚企安数据恢复工程师根据数据情况编写程序扫描&重组所有服务器组件，获取到所有组件信息中的ID信息和所隶属的对象ID等信息。5、提取所有可用数据后，北亚企安数据恢复工程师根据描述信息中记录的组件逻辑位置信息进行数据重组，拼接出完整的vmdk文件。将提取到的所有快照的vmdk文件的快照和父盘进行合并，解析后提取其中的数据文件。所幸数据恢复所需的信息完整。8、用户方工程师验证恢复结果后，确认恢复出来的数据完整可用，本次数据恢复工作完成。4、利用这些信息追溯每一个数据块在所隶属的组件内的逻辑位置，提取数据。

某品牌EqualLogic PS6100存储阵列上有一组由16块硬盘组建的raid5磁盘阵列。磁盘阵列上层划分多个大小不同的卷，存放虚拟机文件。硬盘出现故障导致存储阵列不可用，需要恢复存储阵列中的数据。

将阵列内所有硬盘做好标记后从服务器取出，挂接到北亚企安数据恢复专用服务器上，对所有硬盘以只读方式做完整镜像。2、北亚企安数据恢复工程师基于镜像文件分析raid结构，获取重组raid所需的信息（条带信息、条带分布规律、校验方向、meta区域等）。服务器运行过程中突然崩溃，管理员查看raid阵列状态，发现阵列中2块硬盘掉线，热备盘没有启用。3、根据获取到的raid信息虚拟重组raid5阵列，解析虚拟磁盘的文件系统数据。5、经过用户方工程师的验证，确认raid5阵列内的所有数据恢复完整，应用正常。

1、硬件工程师对出现故障的raid5阵列中的27块硬盘做硬件故障检测，发现其中2块硬盘存在坏道、SMART的错误冗余级别已经超过阈值，其他25块硬盘正常。某单位一台某品牌DS5300存储，1个机头+4个扩展柜，50块的硬盘组建了两组RAID5阵列。同步完成后，上层的卷直接可以使用了，所有数据也都可见，上层应用也能正常使用。分析两块硬盘的掉线时间，搞清楚数据较新的那块硬盘，使用数据较新的硬盘来恢复数据。方案一：通过存储设备的管理软件强制上线，强制上线之前把存储的所有硬盘进行备份。本次数据恢复工作完成。

当第三块盘盘片划伤导致掉线时，RAID崩溃），无法通过校验直接获取丢失盘的数据，所以只能使用磁盘同等大小的全0镜像进行重组（此方法只可用于紧急情况，因为依赖空镜像组成的raid文件系统结构会被严重破坏，相当于每个条带都会缺失两个块的数据）。因为合并快照前的父盘写入较早，使用第一块掉线盘进行校验获取到这个文件的完整数据，然后提取出其中数据库各个表的表结构，之后用户方提供了最新版的数据库建表脚本。8、因为数据库使用时间已久，表结构也曾多次变更，加上系统表在存储损坏后也有部分数据丢失，记录提取过程遇到很大阻力。

8、通过对文件系统的完整解析，将raid阵列内的数据完整导出。2、将存储设备上的所有硬盘上的数据以只读方式完整镜像，后续的数据分析和数据恢复操作都基于镜像文件进行，避免后续操作对原始数据造成二次破坏。3、分析每一块硬盘，发现两块热备盘上没有任何数据，也就是说被激活的热备盘也同样没有同步到任何数据。4、使用北亚企安自主研发的数据恢复工具分析该组raid5阵列的基础信息，虚拟重组raid5磁盘阵列。5、重组出raid5阵列后，数据恢复工程师分析lun信息，然后解析和导出lun数据的map。

多数情况下，执行fsck后INODE会被清除，即使目录信息还在，也无法与数据一一对应，这样就只能参考文件内部格式进行类型式的恢复。映射到新服务器后，服务器对这个卷进行初始化的操作，原solaris系统上的磁盘报错，重启服务器后这个卷已经无法挂载。SUN光纤存储系统中有一组由6个硬盘组建的RAID6，划分为若干LUN，MAP到跑不同业务的服务器上，这些服务器上运行的是SOLARIS操作系统。3、服务器数据恢复工程师分析用户需要恢复的特定文件，发现采用vfs的索引文件具有强的类型特征，同时文件中包含目录信息。

本案例中的数据库没有备份，也没有开启binlog，前两种方案都不适用。此方案的原理为模拟innodb引擎记录管理方式，根据表结构信息将二进制文件解析为字符记录。在本案例中的mysql数据库未进行备份，也未开启binlog日志，无法直接还原数据库。4、数据恢复完成后，北亚企安数据恢复工程师通知用户方验证提取结果，并统计恢复记录总数。3、本案例中，用户方提供了数据库表结构脚本，可以使用本工具中的5+3功能进行恢复。5、用户方验证后表示数据恢复结果完整，总数符合原表内记录条数，本次数据恢复成功。

提取ZVOL卷头部信息，按照XenStore卷存储结构进行分析，发现该vhd在整个卷的尾部，计算得到其起始位置后从此位置开始提取数据。ZFS对所有磁盘进行统一管理。在数据存储时，ZFS会为每次写入的数据分配适当大小的空间，并计算得到指向子设备的数据指针。常规RAID通常可以通过校验机制，利用剩余磁盘上的数据来恢复丢失的数据，因为它在存储时已经按照固定的规则分布了校验信息。4、经过分析发现此存储中的ZFS版本与开源版本有较大差别，无法使用原先开发的解析程序进行解析，所以数据恢复工程师重新编写数据提取程序。

检查到坏道停止时，记录进度数值，如22%，若硬盘容量2GB，坏道起始位置约在440MB处（2GB * 22%）。相比较物理坏道来说，逻辑坏道的修复非常简单，借助Windows系统的磁盘扫描工具，在资源管理器中选中盘符后单击鼠标右键，在弹出的驱动器属性对话框中依次选择“工具”——“开始检查”。坏道分散时，程序产生多个分散可用分区，但主分区仅4个，程序自动选最大4个设为可用，其余隐藏。5、磁盘自动扫描：每次系统开机时，都会自动运行Scandisk扫描磁盘错误，这不仅增加了开机时间，也反映出硬盘存在潜在问题。

将所有硬盘以只读方式做全盘镜像，镜像完成后将所有硬盘按照原始状态还原到原服务器上。2、基于镜像文件分析raid结构（盘序、校验方式、数据块大小等），根据通分析获取到的数据重组raid。重组后进行逻辑校验，逻辑校验通过，所有参数正确无误。4、北亚企安数据恢复工程师将恢复出来的数据迁移到用户方准备好的服务器内，经过检测没有问题。本次数据恢复工作完成。某品牌服务器中有12块硬盘，组建了一组raid5磁盘阵列，服务器内存储的是普通文件。机房供电不稳定导致服务器断电，管理员重启服务器后发现服务器无法正常工作。

避免对原始磁盘数据造成二次破坏。6、北亚企安数据恢复工程师根据丢失文件的文件目录节点号与提取的文件夹名称逐一配对，分析丢失的目录结构。10、提取完数据后，用户方对恢复出来的数据进行验证。扫描该位置，并提取符合丢失的目录结构信息。9、将lost+found文件夹中找到的文件记录号与数据库记录号进行配对，提取数据。2、基于镜像文件分析所有硬盘的底层数据，发现服务器内数据目录项被破坏。3、排查被破坏的目录项信息，发现部分遭到破坏的目录项数据可以修复。8、将上述提取到的信息与目录项节点号对接，记录到数据库内。