ITPub博客

一、存储故障描述我中心接到某公司一台EMC存储数据恢复。经初步了解，这台存储共包含12块硬盘，组成raid5磁盘阵列，包含热备盘2块，单盘容量为1TB，由于硬盘故障导致存储崩溃。二、硬盘物理检测及存储数据备份工程师对客户存储内的所有硬盘进行物理检测，未发现坏道等其他物理故障，随后使用winhex将存储内的所有磁盘进行了备份，备份完成后将客户的原始存储交还给客户，接下来将在镜像文件中进行数据恢复操作

IBM X3850服务器介绍：IBM X3850是 一款定位在企业级的机架式服务器，配备2个热拔插扩展槽+5个非热拔插扩展槽。标配CPU处理器型号为Xeon MP 7120N。最小2?GB内存，根据具体服务器型号可扩展至256?GB。服务器基础性能和扩展能力较高，适合对密集型部署的大中型数据库服务、动态Web应用等。服务器数据恢复背景：数据恢复公司接到某公司送检的一台X3850服务器，客户描述这台

关于虚拟机快照文件被删除的恢复方式跳跃性较强，且没有名词解释，导致产生歧义。为了验证方案可行性，工程师特别对此类案例进行了案例还原，来分步演示虚拟化平台SeSparse数据恢复方法，具体数据恢复演示过程如下。1、搭建环境 在虚拟化平台创建虚拟机（父盘VMDK大于2T），为了后期导出进行观察，创建模式为精简。2、在新建的虚拟机内写入文件，便于观察快照索引与父盘数据之间的联系。3、创建快照文件，再写入

【MongoDB数据库环境介绍】近期，数据恢复中心恢复了某地海关的一台MongoDB数据，首先介绍数据库环境：发生数据丢的数据库位于一台虚拟机上，虚拟机操作系统为WindowsServer 2012。由于业务需要对数据库内的文件进行迁移，于是管理员在MongoDB服务开启状态下将数据库文件复制到其他分区，原始数据库分区下的数据进行了格式化操作。但迁移后的数据无法使用，管理员将数据拷贝回原始分区后M

近日北亚小编收到来自技术部的解决方案《存储设备IBM DS5020故障离线》，经客户描述故障情况如下：客户故障存储为IBM DS5020存储设备，共创建了四组RAID 5，未设置热备硬盘。在设备使用过程中，其中一组RAID 5上，有2块硬盘先后因故障离线，导致此RAID 5失效，数据无法访问。当遇到这种情况应该怎么办呢？跟着小编继续往下看吧！

一台服务器，上层搭建了raid5磁盘阵列，共有5块硬盘在运行用于公司数据的存储，没有备份文件，有一天服务器上有一块硬盘掉线，遂聘请外部运维公司对服务器进行维护，运维公司人员在没有了解具体情况下直接对服务器内的4块正常硬盘重建成了一组全新的raid5阵列，直接导致服务器原有数据全部丢失。

服务器数据恢复故障北京某公司的一台服务器，上层数据类型为Oracle数据库，由于服务器意外断电，导致数据库报错，报错内容为“system01.dbf需要更多的恢复来保持一致性”。由于客户的数据库并没有备份，仅有一些断断续续的归档日志，现在只能通过数据恢复手段来修复Oracle数据库。数据恢复常规流程检测数据库故障情况； 尝试挂起并修复数据库；解析数据库文件；导出并验证恢复的数据库文件检测

【服务器raid5阵列数据恢复故障情况描述】客户的某品牌服务器，raid5磁盘阵列数据恢复需求，服务器不存在物理故障，数据丢失的原因是误删除了服务器上的卷。可以从raid5磁盘阵列层面进行数据恢复操作。【服务器数据恢复过程】服务器数据恢复第一步：分析超级快信息，记录raid阵列起始块位置。工程师对客户的服务器raid阵列进行数据分析，得到阵列的逻辑起始块位置号，服务器数据恢复第二步：去除raid阵

【故障描述】一台StorNext服务器，服务器里有一组raid5磁盘阵列，阵列上先后有两块硬盘因为物理故掉线，raid5磁盘阵列发生故障，需要进行服务器数据恢复操作，并携带服务器内所有磁盘来到数据恢复中心进行数据恢复操作。【磁盘备份】数据恢复中心使用数据恢复工具对客户服务器内的所有磁盘进行只读模式下的镜像备份，首先将客户服务器内的所有正常硬盘进行标记并接入只读镜像设备上进行备份，对两块有故障的硬盘

对服务器进行重装系统操作失误导致磁盘分区发生变化，原服务器内的第二分区由于未知原因不可访问，分区内的数据丢失。经过对客户服务器的xfs文件系统分析，分析结果为文件系统头部超级块丢失，文件系统的部分目录项丢失，部分就节点丢失。根据超级块备份及文件系统中的目录树结构，对超级块进行修复还原，对丢失的节点、目录项进行修补、重构之后，文件系统中99%以上的数据可以完整恢复

由于用户误操作，将Linux文件系统误装入到Ocfs2文件系统的数据卷上，导致原始Ocfs2文件系统被新格式化Ext4文件系统，据对两种文件系统格式化方式的了解，Ext4文件系统每隔几百兆会写入文件系统的原始信息的特性，用户的数据可能受到一定程度的破坏。

本次恢复的数据库安装在客户本地服务器上，服务器操作系统为windows2008 r2 。在当前环境内安装有mysql5.6单实例，引擎类型为innodb，表内数据存储所使用表空间类型为独立表空间。未进行数据库备份，未开启binlog。 导致数据丢失的原因是由于人为误操作使用Delete命令进行删除数据时未添加where子句进行筛选导致全表数据被删除，删除后未对该表进行任何操作，需要从数据库层面进行误删除的数据恢复操作。

本次数据恢复服务器为SUN 光纤存储系统，中心存储为6枚300G硬盘组成的RAID6，划分为若干LUN，MAP到不同业务的服务器上，服务器上运行SUN SOLARIS操作系统。本来服务器并没有物理故障，出于用户业务需求需要再增加一台服务器用于新增应用。于是服务器管理员在原服务器在线的状态下将其中一个lun映射到一台心服务器上

服务器数据恢复操作通常都是基于恢复raid组进行数据恢复操作的，因此本次数据恢复操作也同样需要对raid阵列基础信息进行分析，从而重组raid结构。 经过数据恢复工程师对每一块硬盘的分析发现，客户原服务器内的两块热备盘内全部没有任何数据，也就是说即使被激活的热备盘也同样没有同步到任何数据，两块热备盘从实际上而言并没有发生任何作用。想要恢复数据，只好继续恢复原raid5阵列的其他基本数据，重组raid5.

今天介绍的是服务器raid5阵列因为不明原因导致阵列崩溃后的故障排查方法，以及服务器数据恢复过程。下面简单介绍一下需要恢复数据的服务器硬件配置情况： 本次数据恢复案例中的服务器型号为某品牌X3850型号，服务器上组建了一个raid5磁盘阵列，阵列里包含4块成员盘和1块热备盘一共5块。 服务器再正常使用过成功突然崩溃，管理员查看raid阵列状态时发现阵列中有2块硬盘掉线，热备盘没有启用。需要从服务器层面进行数据恢复操作。

一、vsan分布式存储故障情况介绍近期处理了一个vsan分布式存储的数据恢复案例，需要进行数据恢复的服务器是一套vsan超融合基础架构。由于客户的服务器供电异常导致异常关机，服务器管理员对服务器进行了重启，重启后发现vsan存储逻辑架构出现故障，虚拟磁盘文件丢失，虚拟机组件异常。客户的vsan存储服务器里面一共搭配了16块硬盘，其中固态硬盘有8块，机械硬盘8块。固态硬盘主要作为缓存盘使用。二、vs

    今天为大家介绍一个Linux服务器数据恢复成功案例，本次服务器数据恢复物理服务器请款如下：客户故障服务器为一台X3850服务器，这个服务器是由4块146G SAS硬盘组成的RAID5作为存储介质，文件系统全都是reiserfs。我们首先经过分析发现了之前的硬盘数据组织结构是由一个不到100M的boot分区，后接一个271G的LVM卷，之后是2G的swap分区。

服务器硬盘物理故障情况简介：服务器简单来说就是计算机的一种，具有高速的CPU运算能力、长时间的可靠运行、强大的I/O外部数据吞吐能力以及更好的扩展性。多数企业配备有自己的服务器，同时也带来了服务器故障导致数据丢失的困惑，毕竟更换一台新设备无法恢复原有的设备，今天给大家简单介绍一下服务器硬盘故障导致数据丢失后的数据恢复方法，下面是案例背景。北京某公司的一台服务器出现了硬盘故障，导致服务器瘫痪，数据丢

HP SMART ARRAY在创建一组新的RAID5时，默认会全盘重建所有块校验，也就是说在组成RAID5的任一条带中，总有一个校验块的数据是创建时生成的，相对于原先的有用数据而言，即是破坏的。经过分析，后生成的4块盘RAID5是按双循环，64K块大小，16次条带换校验的方式组织的，也就是说在4块磁盘成员中，大约每隔3M便会有1M的数据是错误的。

发现服务器的目录项已经遭到了破坏，所幸运的是这些目录项的破坏并没影响到服务器的重要数据，仅仅是将目录项破坏了一些，这些破坏可以通过人工进行修复。由于客户的服务器管理员进行过修复操作，这也就导致了损坏的目录项本质上并没有被成功修复，而是以节点号进行命名同时存放到了lost+found文件夹内，对应的数据区索引也被服务器进行了自动清除。