服务器数据恢复背景

北京某国企的一台服务器在正常运行过程中突然崩溃，该服务器共有240块硬盘，其中元数据存储使用了24块硬盘，硬盘搭配情况为9组raid1磁盘阵列和1组raid10磁盘阵列。其余所有硬盘平均组成了36组raid5磁盘阵列。而到这这一存储瘫痪的最终原因是其中的一组磁盘阵列中有2块硬盘先后离线，进而影响到整个服务器无法使用，只好联系北京数据恢复公司进行上门检测和恢复服务器数据。

数据恢复中心安排工程师来到客户现场对故障服务器进行简单初检和评估随后开始进行数据备份。由于离线硬盘属于同一组raid阵列，所以对服务器采取两种不同的备份方式，即对离线的raid进行全盘扇区级镜像，其他未出现离线硬盘的raid阵列进行存储层面备份即可。在对故障raid阵列的备份过程中发现两块掉线的硬盘中有一块硬盘存在着大量的不规则坏道导致无法进行继续备份，只好对该硬盘进行固件更换和修复后继续备份，但大量的坏道依然存在。

数据分析

服务器数据恢复工程师首先对故障的RAID阵列底层结构进行详细分析，然后根据分析出来的raid信息虚拟重组出raid阵列进行进一步分析。通过进一步分析发现坏道极多的那块硬盘离线较晚，可能对最终的数据恢复结果产生一定影响。

登录到存储设备的管理系统获取文件系统中关于卷的基本信息发现文件系统中有2个卷，再继续分析Meta卷的目录和节点信息以及Meta卷到Data卷的索引算法。

服务器数据恢复成功

经过服务器数据恢复工程师的努力分析获取到了数据恢复必须的基础信息后，工程师通过编写程序进行节点和目录项扫描解析，导出文件系统的完整目录结构，解析每一个节点中的指针信息，将这些信息记录在数据库中。

客户对工程师恢复出的所有数据进行了随机抽样检测后确认数据完整，同意移交数据恢复结果，本次服务器数据恢复成功。

[磁盘阵列数据恢复故障描述]

北亚数据恢复中心接收到客户的一台HP DL380 G4服务器，服务器使用hp smart array控制器挂载了一台国产磁盘阵列，磁盘阵列由14块146G SCSI硬盘组成一组RAID5。操作系统为LINUX，构建了NFS+FTP，作为公司内部文件服务器使用。由于服务器机房进行搬迁，搬迁过程中管理员顺便打扫了一下服务器和磁盘阵列设备，随后在新机房链接线路后服务器无法识别RAID，未做初始化。

[磁盘阵列初检结果]

工程师对设备进行简单的初检,发现数据丢失的原因为raid信息丢失,HP smart array系列控制器源自康柏，RAID中的冗余采用双循环的校验方式。

[raid数据恢复步骤]

1、先将SCSI硬盘柜直接连接到不包含有RAID功能的SCSI扩展卡上。

2、然后工程师们在专用(windows2003改装后)的修复平台上以单盘的方式连接服务器阵列中的所有硬盘。

3、为了保护客户原有数据,避免因数据恢复操作更改客户原始数据,在所有的数据恢复过程中都必须对所有硬盘以只读方式做完整镜像，同时镜像亦存储于带冗余保护的设备上。

4、安排工程师从镜像文件中分析原RAID的双循环校验参数,搭建虚拟raid平台。

5、在虚拟RAID平台去掉早离线的盘，解释文件系统，此时已经可以导出raid数据。

6、在客户原HP 服务器上连接盘阵，重新配置RAID。

7、最后通过网络dd、NFS、SAMBA、FTP、SSH等数据传输方法把所有数据传回新建的raid磁盘阵列中。

[数据恢复结果]

Raid中所有数据100%恢复成功,全部工作历时2 天。

[服务器存储安全建议]

1.尽量保证机房电源供应稳定，以减少电源异常对主机及存储的冲击；

2.最好为重要的服务器及存储配置UPS，可在机房意外断电的情况下保证核心业务系统能继续维持一定时间的正常工作，从而为企业寻求应急解决方案赢得宝贵的时间；

3.对于服务年限已久的服务器应定期进行安全状况检查，并对其整体运行状态进行评估以决定是否进行硬件及系统的全面升级，同时提前制定突发数据灾难的紧急处理方案，以降低数据灾难带来的业务损失。

今天我给大家分享的是一篇关于raid磁盘阵列数据恢复的案例，本案例中包含了对磁盘阵列的修复和重组过程，raid数据恢复中的方法比较通用，希望在数据恢复方面对大家有所帮助。

Raid阵列情况介绍：

需要进行数据恢复的阵列搭建在一台某品牌的S5020型号光纤存储上。这个磁盘阵列中一共包含了14块硬盘，其中10号硬盘和13号硬盘出现了故障警报，卷也无法挂载，存储无法继续工作，需要对存储进行数据恢复并修复其中的数据库。

开始恢复raid磁盘阵列：

通过storage manager连接这台存储设备进行查看发现存储报告逻辑卷状态失败，阵列中的10号盘和13号盘报告失败，6号硬盘报告警告，数据恢复工程师只好先通过备份的日志状态进行逻辑卷的结构进行尽可能多的数据分析，以为后期的数据恢复工作提供数据。

机房管理员把这14块硬盘全部从存储设备中取出然后交给raid数据恢复工程师借助数据恢复工具进行初检，初检后发现该磁盘阵列中的所有磁盘都可以正常识别，但是6号盘的smart状态依然为“警告”状态。

Raid数据恢复工程师将阵列中所有磁盘状态标记为“脱机”（注：这样做的目的是为了保护原始磁盘），然后借助数据恢复工具对磁盘阵列中的所有磁盘进行镜像备份。工程师在进行备份的过程中发现先前报错的6号硬盘速度十分缓慢，可以进一步确定该盘一定存在大量损坏或者不稳定的扇区，需要对其进行单独处理。于是改用坏道硬盘的镜像设备单独对6号硬盘进行坏道镜像并且密切观察镜像的稳定情况和镜像的速度情况。（通常情况下如果硬盘存在大量的不稳定扇区，可以将坏到硬盘镜像设备的响应等待时间、遇到坏道跳过扇区的数量等参数进行修改和调整，指导所有扇区全部镜像完成）

等到磁盘阵列中的所有磁盘全部镜像完成后查看日志，查看日志后发现1号硬盘其实也存在有坏道，10号盘和13号盘也存在大量的不规律坏道，

工程师对文件系统进行逆向分析后得到了raid磁盘阵列中的硬盘盘序、raid校验方向、块大小等基本信息用来重组raid，将raid磁盘阵列搭建完成后数据恢复工程师再进一步分析文件系统、提取数据库的dmp文件并导入，数据恢复成功。

数据验证通过，raid数据恢复成功

客户对恢复出的数据进行验证通过，本次raid数据恢复成功。

一、故障描述

成都某客户，存储损坏，数据库崩溃。重组存储，恢复数据库文件，发现有四个ndf文件大小变为0 KB。数据库大小约80TB。数据库中有1223个文件，数据库每10天生成一个NDF文件，每个NDF大约500GB，数据库包含两个LDF文件。

二、故障分析

存储损坏，NDF文件大小变为0 KB，根据NDF文件在磁盘上可能存在。可以通过编写数据库扫描碎片程序，扫描数据库碎片、拼接碎片恢复NDF文件，然后修复数据库。

三、恢复过程

1 磁盘扫描，扫描数据库碎片

2 拼接碎片;根据NDF文件的页面特征，按照文件号，页号拼接碎片，重组生成出这些0kb的NDF文件。

3 检测数据库文件;使用北亚MSSQL文件检测工具对所有数据文件进行检测，结果：拼接出的4个NDF文件有少量的空页，其他文件正常。

4 进一步对损坏lun进行分析，发现这些数据页在存储层面已经不存存在了。不能恢复这些数据页，即这4个文件不能完全恢复

5尝试附加数据库，报错 “处理数据库的日志时出错，如果可能请从备份还原。如果没有可用的备份，可能需要重新生成日志”。

6、无日志附加数据库;修改系统表，从系统表剔除掉最后添加的LDF文件，计算并修改校验。进行无日志附加数据库。报错：数据库存在一致性错误，图一：

7 修改系统表中这4个损坏的NDF文件的块数量，使其和恢复出来的文件的块数量一致;修改系统表，将系统表记录这4个NDF的块数量的值改为和扫描出来的NDF文件块数量一致，同时更改这4个NDF文件首页，使得数据库中记录的文件的块数量和拼接出来的NDF的块数量一致，计算并修改校验值。

8 无日志附加数据库，报错数据库存在一致性错误，图二

9 逐个修改系统表中这4个损坏的NDF文件的块数量，使其值等于报错块前一页;分析报错，由于空页都出现在这4个NDF后面十几个块中，截断文件对数据完整性影响不大。重新修改系统表和NDF文件，将数据库中记录NDF块数量的值改至报错的前一页，计算并修改校验。

10 、重新进行无日志附加数据库，报错“由于数据库没有完全关闭，无法重新生成日志”图三：

11、修改MDF文件中的数据库的状态值，让数据库认为是完全关闭的

12、重新附加数据库，附加成功。图四：

四、结果

数据库文件成功附加后，客户通过数据库中的对象进行初步查询、验证，表中信息基本完整，数据得到恢复。数据验证完毕，客户对恢复结果表示满意。

磁盘阵列两块硬盘离线数据恢复案例一：

客户使用Dell 2850服务器组建了raid5磁盘阵列，阵列中包含有6块硬盘（SCSI硬盘，单盘容量300G），服务器操作系统为linux Redhat4；文件系统为ext3文件系统。在使用过程中服务器瘫痪，管理员对阵列检查后发现有两块硬盘离线，对其中一块硬盘进行了强制上线操作，但操作系统启动异常。管理员此时意识到事情的严重程度，马上对服务器进行关机，然后联系到数据恢复中心进行数据恢复。数据恢复中心初检结论：在服务器数据恢复工作中，raid5两块硬盘离线的情况十分常见，由于raid5磁盘阵列支持一块硬盘离线时的荣誉保护，一旦多块硬盘处于离线状态，服务器便处于瘫痪状态，且不会自动上线。由于raid控制器具有一定的面感性，多数硬盘掉线紧紧是因为电源波动、控制器bug等随机原因导致，所以掉线盘可能没有严重的物理故障。本案例就是如此。但是此时管理员进行强制上线操作风险性是很大的，一旦上线错误就会导致控制器对数据产生一些不可逆的损坏，当管理员进入操作系统后因为文件系统不一致进行修复，服务器中所有硬盘数据不一致，数据恢复难度非常大。服务器数据恢复过程：首先对服务器中所有硬盘进行完整备份，在备份过程中发现多块硬盘已经存在坏道但没有下线，原因是raid没有读到硬盘坏道。备份完成后分析原服务器的raid组成结构然后虚拟出raid环境对raid结构畸形验证，把服务器后期破坏的结构进行人工修正，将修正后的数据导出到一台中间存储上临时存放。数据恢复的最后一步使用完好的硬盘在服务器上搭建新的raid5磁盘阵列，将恢复出的数据迁移到新raid中即可。检验恢复出来的数据一切正常，数据成功恢复。服务器数据恢复结论：一旦raid5磁盘阵列出现多块硬盘离线、服务器瘫痪的情况切记不要盲目进行强制上线操作，如果有足够的备用空间，可将源硬盘全部镜像。有两种方法（WINDOWS2003或DOS下，其他操作系统有风险）：1、可用相同或大于源盘容量的硬盘做为目标盘，将源盘全部扇区方式CLONE到目标盘。将所有盘做同样操作。2、可将每块源盘完全以扇区方式输出文件到某大容量存储空间（如大容量硬盘、NAS、SAN、DAS等）磁盘阵列两块硬盘离线数据恢复案例二：

HP LH6000的故障如下: 一块硬盘红灯闪亮，机器还在正常运行，但没有多久，系统就不能正常运行，这时才发现另一块硬盘的红灯也在闪亮。磁盘阵列数据恢复过程：1.启动服务器，自检至阵列时按Ctrl+M进入NetRaid管理程序。查看阵列信息，发现硬盘状态为Failed，运用修改配置将一硬盘强行设置成OnLine。重新启动服务器，在进入系统前的硬件自检时无效，启动失败。2.启动服务器，自检至阵列时按Ctrl+M进入NetRaid管理程序。选择磁盘阵列，将原来OnLine挂起来的硬盘手工Fail掉，然后再把另一块Failed的硬盘手工设置成OnLine，重新启动服务器就可以进入系统了。3.查看系统及数据库都运行正常后，再进阵列配置工具把Failed的硬盘手工设置成Rebuild，100%完成重建后再重启服务器，所有的阵列及系统都恢复原状了。 笔者所在单位另一台运行ERP系统的服务器(HP ProLiant 文明用语370)，由4块146GB热插拔硬盘通过RAID卡(Smart array阵列卡)配置成一台具有RAID 5级的磁盘阵列。其中一块硬盘在运行过程中突然出现故障。服务器RAID 5自动启用热备份硬盘(Hot Spare)，对损坏硬盘进行逻辑替代。整个硬盘的数据访问任务仍然完整地运行在原来的读写进程序列中，应用程序和数据库没有发生影响。通过HP自带的ACU工具查看硬盘状态进行检查，发现红灯示警的硬盘处于脱机状态。如果HP ProLiant服务器中的Raid 5有两块硬盘出现亮红灯时，表明系统已经崩溃，数据库也就不能访问，但系统不会自动关机。当第二块硬盘亮红灯后，用常规的手段是不能恢复数据的，只有付费找专业的第三方数据恢复公司恢复数据。因此，对惠普老型号HP LH6000系列服务器来说，阵列的设计方面与现在HP ProLiant系列服务器的阵列有很多不同。就操作方法看，HP LH6000服务器的阵列操作方法有很多可选项，包括阵列失败后可以重新删除阵列并重建等，初始化也是手工选择的。但是HP ProLiant系列服务器阵列的初始化是在配置阵列后自动在后台执行的，所以ProLiant系列服务器在阵列出错后是不能重配阵列的。

一、服务器数据恢复故障描述

整个服务器的存储结构是由一台控制器，三台扩展柜和28块FC 300G硬盘构成的。由于两块磁盘掉线导致存储某些LUN不可用，某些LUN丢失。由于服务器是因为某些磁盘掉线从而导致整个设备不可用。因此接收到磁盘以后数据恢复工程师先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。磁盘坏道检测日志如下：

二、服务器数据恢复备份数据

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一操作不当导致数据无法再次恢复。使用winhex将所有磁盘都镜像成文件，源磁盘的内容数量多，在做数据备份的时候要花费很长时间。备份完部分数据如下：

三、故障分析及服务器数据恢复过程

1、分析故障原因

由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为EVA控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，EVA控制器就认为是坏盘，就将认为是坏盘的磁盘踢出磁盘组。而一旦某个LUN的同一个条带中掉线的盘到达极限，那么这个LUN将不可用。即如果EVA中所有的LUN都包含这些掉线的盘，所有LUN都会受影响。掉线两块盘导致整个存储的LUN都不可用的情况就很正常了。而目前的情况是现存8个LUN，损坏7个LUN，丢失6个LUN。需要恢复所有LUN的数据。

2、分析LUN的结构

HP-EVA的LUN都是以RAID条目的形式存储数据的，EVA将每个磁盘的不同块组成一个RAID条目，RAID条目的类型可以有很多种。我们需要分析出组成LUN的RAID条目类型，以及这个RAID条目是由哪些盘的哪些块组成。这些信息都存放在LUN_MAP中，每个LUN都有一份LUN_MAP。EVA将LUN_MAP分别存放在不同的磁盘中，使用一个索引来指定其位置。因此去每个磁盘中找这个指向LUN_MAP的索引就可以找到现存LUN的信息了。

3、分析服务器丢失的LUN

虽然磁盘中记录了指向LUN_MAP的索引，但是它只记录现存的LUN，丢失的LUN是不会记录索引的。由于EVA中删除一个LUN只会清除这个LUN的索引，而不会清除这个LUN的LUN_MAP。这时需要扫描所有磁盘找到所有符合LUN_MAP的数据块，然后排除掉现有的LUN_MAP，剩下的LUN_MAP也不一定全是删除的，也有一些是以前旧的，但此时是无法在LUN_MAP中筛选了，只能通过程序将所有LUN_MAP的数据都恢复出来，人工的去核对哪些LUN是删除的。

4、分析服务器掉线磁盘

在前面的故障分析中说了，虽然磁盘没有明显的物理故障，也没有磁盘坏道。但还是会因为性能的原因从EVA磁盘组中脱离。而这些脱离的磁盘中都存放的是一些旧的数据，因此在生成数据的时候需要将这些磁盘都排除掉。但是如何判断哪些磁盘是掉线的呢？由于LUN的RAID结构大多都是RAID5，只需要将一个LUN的RAID条目通过RAID5的校验算法算出校验值，再和原有的校验值做比较就可以判断这个条目中是否有掉线盘。而将一个LUN的所有LUN_MAP都校验一遍就可以知道这个LUN中哪些RAID条目中有掉线盘。而这些RAID条目中都存在的那个盘就一定是掉线盘。排除掉线盘，然后根据LUN_MAP恢复所有LUN的数据即可。

5、编写服务器数据恢复程序

上述的故障分析以及解决思路最终都需要使用编程来实现。编写扫描LUN_MAP的程序Scan_Map.exe，扫描全部LUN_MAP，结合人工分析得出最精确的LUN_MAP。编写检测RAID条目的程序Chk_Raid.exe，检测所有LUN中掉线的磁盘，结合人工分析排除掉线的磁盘。编写LUN数据恢复程序Lun_Recovery.exe，结合LUN_MAP恢复所有LUN数据。

6、恢复所有LUN数据

根据编写好的程序去实现不同的功能，最后使用Lun_Recovery.exe结合LUN_MAP恢复所有LUN的数据。然后人工核对每个LUN，确认是否和甲方工程师描述的一致。部分LUN的数据恢复如下：

四、数据验证

客户对数据恢复出的所有数据进行检验，数据完整，本次服务器数据恢复成功

日后数据安全建议

安排员工经常巡视机房，发现有报警信息及时处理。管理人员操作存储要谨慎，避免误操作导致数据丢失。现场发现EVA控制器部分模块不太稳定，应当及时更换。由于EVA存储故障是由磁盘不稳定引起的，而这部分磁盘应该是同一批次的磁盘。因此，这些磁盘的性能也快到极限，如果有条件建议换掉这批磁盘。

【服务器数据恢复介绍】

北京某公司的一台服务器在正常运行过程中因为未知原因忽然崩溃，管理员对服务器进行检查发现有一块硬盘离线，只需更换故障硬盘即可，于是管理员对服务器进行更换硬盘并同步数据，但是在更换新硬盘后进行数据同步的过程中服务器中的另一块硬盘又忽然掉线，如此一来客户的服务器彻底瘫痪了，逻辑盘无法挂载，进入服务器的管理界面查看发现有两块硬盘的状态为故障脱机

【服务器数据恢复备份】

服务器数据恢复的第一步也是必须要做的一步就是对故障服务器进行全盘备份，因为在数据恢复的过程中不可避免的要对数据进行分析和数据重组工作，并且这些工作往往需要进行多次重复分析和提取，如果在原始设备上进行分析重组必然会对服务器的原始数据进行破坏，如此一来一旦由于数据恢复工程师技术原因导致数据恢复失败的话就会导致原始服务器内的数据被破坏，其他数据恢复公司再进行数据恢复操作时难度增加甚至导致原始数据被彻底损坏无法恢复。所以在进行服务器数据恢复时首先要对服务器内的所有磁盘进行备份操作，在进行备份时数据恢复工程师们大多借助数据恢复工具进行全盘镜像（尤其是有故障的硬盘必须使用专业设备进行备份，普通方法无法进行镜像操作）

【制定服务器数据恢复方案】

服务器数据恢复方案一、如果离线硬盘没有物理故障那么对服务器进行强制上线操作是修复服务器故障的最简单的方法，一般情况下将后离线的硬盘进行故障修复，然后重新连接服务器后进行强制上线即可，如果故障硬盘离线的原因是硬盘物理故障那么强制上线不仅会失败而且还会增加raid卡负担，是无法通过强制上线进行恢复数据的。另外即使硬盘不存在物理故障采用强制上线的方法进行数据恢复也存在着一定的风险，我们都知道服务器强制上线后会进行重建，在重建过程中一旦检测到服务器中其他硬盘存在故障那么服务器就可能面临彻底崩溃。由于我们是专业的数据恢复公司，所以本次数据恢复中采取了另一种更为稳妥的数据恢复方案。

服务器数据恢复方案二、通过分析底层数据结构提取原服务器数据。这种数据恢复方案的原理是首先根据服务器的原始配置信息将所有硬盘按照Mdisk组进行分类，分析每一组Mdisk的raid基本信息，然后借助专业的数据恢复工具虚拟重组出Mdisk，然后再对重组的Mdisk进行进一步分析，得到pool信息和pool在Mdisk上的分布情况、pool的条带大小、各lun在pool中的分布情况这些基本信息，然后由服务器数据恢复工程师编写一个小程序进行lun的提取。

【服务器数据恢复结果迁移】

服务器数据恢复工程师将提取出的lun进行验证后将提取出的lun使用dd的方式迁移到新的服务器中，本次服务器数据恢复成功。

服务器数据恢复案例背景：

服务器raid磁盘阵列组瘫痪了，该磁盘阵列中一共有3块硬盘，目前一块硬盘亮红色警报灯，需要重点进行恢复的数据为D盘里的数据库数据。由于存储故障后管理员进行重启服务器导致先前离线的硬盘重新上线并进行了数据同步，幸好同步未完成就进行了强制关机。

服务器数据恢复过程：

服务器数据恢复工程师首先将阵列中的三块硬盘进行了只读的镜像备份，在备份过程中发现该服务器中的三块硬盘都可以正常识别和读取，硬盘没有发现坏道。

然后服务器数据恢复工程师对做好的镜像文件进行了详细分析，通过分析到的raid基本信息进行raid虚拟重组并进行异或校验，对备份的镜像文件进行详细分析，重组raid结构，并进行异或校验，但是由于管理员在数据损坏后又进行过同步操作，这一操作会损坏数据，所以在进行异或校验时结果为部分校验通过，说明数据有损坏。

服务器数据恢复工程师对RAID阵列进行了进一步分析，尝试了多种硬盘离线的状态下分别进行数据提取操作，但每一种尝试所提取到的数据都是一样的。只好首先针对E分区中的dat文件进行分析修复希望可以通过找到备份文件来进行数据恢复，但是数据恢复的结果依然是文件损坏。数据恢复工程师分析聚合dat碎片，验证dat数据完整性，底层结构显示有损坏。

数据恢复工程师尝试了好几种方法进行数据提取但是都失败了，想要恢复被破坏的数据，恢复服务器原有数据只有通过拼接碎片这一种难度最大的方法进行一次最后的尝试。服务器数据恢复工程师对D分区的自由空间进行数据页扫描，将扫描出来的所有碎片进行逐一分析并聚合，对聚合后的文件碎片完整性和有效性进行简单验证后导出备份文件中的数据记录到工程师的新建数据库中。通过上层应用连接数据库，验证数据可用性，数据库文件可以正常加载，上层应用软件中用户账号正常，可以进行正常数据查询。本次数据恢复成功

服务器数据恢复案例总结：

在恢复过程中，在E盘发现2个SealLib数据库的备份文件。但是备份文件数据中页结构有小部分损坏， 在D分区扫描的结果中数据碎片发现较连续的数据片段，碎片可用。通过对D分区碎片和E分区备份文件进行整合拼接。最终修复解析出的数据可以支撑整个应用的正常使用，上层应用可以正常查询数据库内容。数据恢复过程部分截图如下

可以恢复部分，你在电脑上打开360软件大全，搜索北亚数据恢复，有安卓版和苹果版

1

打开“360安全卫士”，切换至“软件管家”选项卡。

2

在打开的“软件大全”窗口中，搜索“手机短信恢复”。并从搜索结果列表中根据自己的手机类型来选择“安卓”和“苹果”两款数据恢复软件其中之一，点击“下载”按钮。

在此小编选择“安卓手机数据恢复软件”。

3

接下来将手机通过USB数据线和电脑相连，同时打开手机中的“USB调试”开关。

4

手机必须获取ROOT权限。其中一种获取手机Root权限的方法是从百度中搜索“刷机精灵”，利用刷机精灵来获取手机ROOT权限。

运行桌面上的“Frombyte recovery for Android”软件，在程序主界面中点击“导出手机数据”按钮。

在确保手机“USB调试”开关正常开启的情况下，从弹出的窗口中点击“加载设置”按钮。

当手机设备信息获取成功后，点击“获取短-信数据”按钮，以便获取短-信数据库文件。

在弹出的文件保存位置窗口中，选择保存至某个磁盘目录中，该目录不能包含中文名称，点击“确定”即可导出短-信数据库文件成功。

接着点击程序主界面中的“新建任务”按钮。

在弹出的“新建任务”窗口中，从“任务选项”下拉列表中选择“短-信息”，然后选择短-信数据库文件，点击“确定”按钮。

接着就会列出当前手机中已存在的短-信和被删除的短-信。

选择“删除的短-信”项，右击已删除短-信列表，选择“导出全部短-信”项。

在弹出的窗口中，点击“保存”按钮就可以恢复短-信内容啦。

最后将生成的短信内容文件用Excel表格打开就可以看到短-信内容。

（本文内容由百度知道网友迎风而立8贡献）

[服务器数据恢复原因推断]

服务器数据丢失情况很多，通常无法明确服务器数据丢失的原因，常见的丢失原因有：服务器硬盘出现故障，管理员或者服务器自动进行fsck操作，这一操作可能造成更加严重数据丢失或者导致服务器数据恢复的难度增加。服务器数据丢失后执行mkfs操作，若操作未完成则容易导致部分块组全部为0。或者管理员在服务器数据丢失后自行尝试恢复数据、数据恢复公司操作不当等都有可能对服务器内的数据进一步造成破坏，增大数据恢复难度。

[服务器数据恢复正确方法]

首先需要对故障服务器的所有数据进行完整镜像备份操作，数据恢复切忌在原盘中进行数据分析和恢复（包括服务器在内的所有存储介质的数据恢复操作均是如此）。对镜像文件进行分析确定服务器的磁盘分区组成情况，剩余空间分配情况，文件系统类型是什么，根分区的超级块状态是否正常，根据超级块状态查看第一块组的描述是否正常以及节点区的状态是否为0。

由于已经查询过第一块组的描述状态，再根据第一块组的描述表对其他块组进行依次分析，查询规律，例如我们在依次服务器数据恢复中发现用户服务器的前26个块组全部是0，最后部分块组的源数据区域同样全部为0，但中间块组区的描述表、节点、BITMAP等信息都是正常状态，块组前面和后面的数据区有明显的用户数据存在现象。

尝试查找服务器的根目录并以此为线索对服务器根目录节点区进行恢复，结合根目录记录生成一个文件系统树，（服务器数据恢复进行到此已经可以看到部分数据）检查文件系统的结构是否正常，注意文件或文件夹的节点是否为0，跟踪文件节点找到节点区处于文件系统的位置。如果在文件系统结构检查中发现有节点区为0的文件或文件夹时则通常很难修复和导出这部分数据。

[服务器数据恢复建议]

如果服务器内部的数据十分重要尽量使用多块硬盘的raid阵列作为存储环境，避免使用单块硬盘进行存储环境搭建；服务器内的数据一定要定期备份，备份包尽量不要存放在同一存储体内，如果条件实在不允许也要避免存放在统一分区内；服务器磁盘出现故障后应尽快做好备份工作，避免非专业人员反复尝试修复；在选择数据恢复公司时尽量选择专业的公司进行操作，避免有意或无意的二次破坏。