如何进行u盘数据恢复？u盘是很多上班族必备的办公工具，不管是出差还是开办公会议，只要把文件存进u盘里，随身携带，方便又省事。但是也有很多上班族遇到这样一个问题：u盘上的数据丢失。有的是自己的失误造成，有的是u盘故障造成。不管是哪一个原因，只要能恢复u盘数据才是最重要的。

U盘上的数据其实很简单，只要我们不要继续往u盘上读写数据，尽量保持u盘上的数据没被覆盖的情况下，我们可以通过万能数据恢复大师恢复丢失的数据。

准备工具：u盘，电脑

U盘数据恢复步骤：

图1：安装软件

步骤2：将u盘插在电脑端的USB插口上，并运行软件，在软件主界面选择要恢复的磁盘（u盘）。

图2：选择u盘

步骤3：进入扫描模式，根据u盘上数据丢失的原因选择扫描模式，如果不清楚是什么原因导致数据丢失，可以选择【深度扫描】。

图3：选择扫描模式

步骤4：进入选择数据类型模式，如果要恢复的是图片，那么勾选图片，以此类推，然后点击【下一步】，软件开始扫描u盘上的数据。

图4：选择数据类型

步骤5：扫描完毕之后，在扫描出来的列表中，根据预览文件的内容，找到要恢复的数据，点击【恢复】，保存路径，u盘上的数据就可以恢复啦。

图5：恢复文件

U盘上的数据是不是如此简单！遇到u盘数据删除的朋友可以下载软件，并结合以上的步骤，在数据没被覆盖的情况下，都能找回丢失的数据！

删除的手机短信应该如何恢复？怎样才能找回手机删除的短信呢？很多时候因为我们的马虎大意经常出现手机数据丢失的情况，可能在一些不仅要的关头，我们不会意识到数据丢失的可怕之处，一旦在紧要关头出现短信丢失就会给我们带来很不好的影响？那么误删的短信应该如何找回呢？怎样可以简单快速的恢复呢？这里就和大家推荐一款可以快速找回误删短信的方法，大家一起了解了解应该如何操作。

如何快速找回手机删除短信教程：

需要使用的工具有：

1.手机数据恢复精灵

2.被删短信的手机

如何快速找回手机删除短信步骤如下：

步骤一：将“手机数据恢复精灵”软件下载并安装在手机上，这里只需根据自己平时的的下载安装习惯进行软件下载安装即可。

步骤二：打开已经安装在手机上的软件，进入界面会有不同的六种数据恢复的选项，我们需要恢复的是手机丢失的短信，点击‘短信恢复’进入就可以了，接下来软件会对手机删除短信数据进行扫描。

步骤三：进入数据扫描阶段，软件会对手机删除的所有短信进行全面深度的扫描，大家耐心等待即可，不会占用大家很多的时间。

步骤四：等待数据扫描结束之后，所有短信扫描的结果都会显示在界面，点击界面任意一条短信，可对短信内容进行查看，依次查看想要查看的短信，接下来勾选需要恢复的短信。

步骤五：查看完短信内容之后，请将需要恢复的短信进行勾选，点击“恢复”按钮就可将删除的短信恢复。

通过以上的步骤就可以将安卓手机误删的短信在手机上找回了，对于很多小伙伴都在使用的苹果手机，其实也会遇到数据丢失的情况，那么应该如何找回呢？通过“强力恢复精灵”看看相关的操作方法。

准备工具(或手机短信恢复需要的工具)：

a>误删短信的苹果手机;

b>强力恢复精灵

具体步骤如下：

1.在手机端打开APP store，搜索并下载强力恢复精灵，按照安装向导进行安装。

2.打开运行下载好的软件，您可以看到软件界面八大功能块，还可以在界面上看到一些使用说明。选中要恢复的模块，点击“短信”一栏，即可进入子界面。

3.软件正在扫描数据，扫描需要一定的时间，请耐心等待。扫描数据时请勿关闭软件。

4.扫描成功后，就可以对误删的数据进行恢复操作了，选中您需要恢复的数据，直到数据恢复完成即可，之后可以在手机上查看到恢复后的短信内容了。

大家按照以上的步骤进行相关短信恢复的操作啦，相信大家都是可以进行操作的，日常生活中大家难免会遇到数据丢失的情况，如果学会了以上的方法之后就不用害怕数据丢失了。

有些人还不会使用迷你兔数据恢复找回被清空数据，所以今日呢，小编就讲解了迷你兔数据恢复找回被清空数据的具体操作。

迷你兔数据恢复工具软件版本：8.1应用工具立即查看

第一步：运行迷你兔数据恢复工具，选择“深度恢复”

第二步：选择数据之前保存的磁盘位置，对这个磁盘进行“完全扫描”(比如数据之前保存在F盘，然后被删除清空，这个时候就扫描F盘)

第三步：等待扫描结束，在丢失数据的列表中手动勾选需要恢复的数据然后保存到安全磁盘中，回收站被清空的数据就恢复出来了

上面就是小编带来的迷你兔数据恢复找回回收清空数据的具体操作教程，小伙伴们都学会了吗?

一.故障描述

客户设备品牌为昆腾系列存储，共10个磁盘柜，每个磁盘柜满配24块硬盘。其9个存储柜用作数据存储使用，另外1个存储柜用作元数据存储使用。

元数据存储中共24块146G硬盘，其中设置了9组RAID 1阵列，1组4盘位RAID 10阵列，4个全局热备硬盘。

数据存储中，每6块硬盘设置一组RAID 5阵列，共36组RAID，这36组RAID阵列中，又分为2个存储系统。其中1个存储系统中，一组RAID由于2块硬盘先后故障离线，导致RAID阵列失效，整个存储系统崩溃，无法使用。存储及文件系统架构大致如下图一：

注：Meta_LUN(元数据卷) Data_LUN（用户数据卷）

二.磁盘备份

为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏, 首先使用WinHex软件对客户的存储环境进行备份。备份过程如下图二所示：

对故障RAID中的6块成员盘进行编号标记，将硬盘从存储柜中拔出，接入到准备好的备份平台上，对6块硬盘进行全盘备份。

对其余没有出现故障的RAID阵列，进行存储层面的备份。使用光纤线缆将备份平台和存储设备连接，进入昆腾存储设备管理界面配置备份平台和存储设备可以正常通信，使用WinHex软件对RAID中的LUN进行镜像备份。

在备份过程中发现故障RAID中的1块故障硬盘存在大量的坏道区域，在备份的过程出现故障，无法继续备份。对故障硬盘进行开盘更换固件，并使用PC3000工具进行修复后，硬盘可以继续备份，但坏道仍然存在。部分镜像文件如下图三：

三.数据分析

首先对故障的RAID阵列进行分析，获取到相关的RAID信息，使用WinHex软件对RAID阵列进行虚拟重组，并将RAID中的LUN恢复成镜像文件。在分析过程中发现，损坏较严重的硬盘为后离线硬盘，由于此硬盘存在大量坏道，可能对最后的恢复结果产生一定的影响。

登陆昆腾存储设备的管理界面，获取到StorNext文件系统中卷相关的一些基本信息，如下图四：

继续对StorNext文件系统中的Meta卷和Data卷进行分析，客户的StorNext文件系统中，包含2个Data卷，每一个完整的Data卷都是由多组RAID中的LUN组成的，对这些LUN进行分析，得到LUN之间组合的算法规律，虚拟重组出完整的Data卷。图五：

分析Meta卷，对Meta卷中的节点信息和目录项信息，以及Meta卷和Data之间的对应关系进行分析，针对一个Meta卷管理多个Data卷的情况，研究得到Meta卷到Data卷的索引算法。文件节点如下图六：

目录块如下图七：

四.数据恢复

通过分析研究我们已经获取到了恢复工作所需全部信息，开始编写程序，扫描Meta卷中的节点信息和目录项信息，同时对目录项和节点进行解析，获取完整的文件系统目录结构，解析每一个节点中的指针信息，将这些信息记录在数据库中。文件信息如下图八：

编写文件提取程序，读取数据库，根据解析出的信息以及两个Data卷之间的聚合算法对数据进行提取。

五.恢复结果

对生成出的数据进行随机抽样检测，数据没有问题。将客户所需全部文件提取到本地，确认提取完成后，到客户线程进行数据移交。数据移交完成，客户对数据恢复结果表示满意。虽然故障硬盘存在有坏道的情况，但万幸核心数据没有遭到破坏，数据恢复工作圆满完成。

删除，是计算机使用中最常见也最频繁的一个操作，通过删除不需要的文件，可以为磁盘腾出更多的使用空间。删除计算机文件时，除了鼠标右键单击该文件删除之外，还可以通过shift+delete这两个组合键来删除，但是后者是把文件删除且不需要经过回收站。由此而来的问题是：如果发现删除了需要的文件，那这些文件应该怎样恢复呢？

计算机的删除原理：

计算机中的删除可分为逻辑删除和物理删除，shift delete删除属于逻辑删除的范畴。逻辑删除指不对文件的数据进行删除清空，不对硬盘数据进行修改，这就使得误删的文件可以被恢复。但文件删除前所占簇是允许覆写的，这就意味着如果删除文件后继续使用文件所在分区可能使得数据被覆盖导致破损甚至无法恢复。

由此我们可以知道，被shift delete删除的文件是可以被恢复出来的，只是要注意，文件一旦被删除后不要再对文件丢失分区进行任何操作，以免分区在不注意的情况下写入新的数据造成数据覆盖或者数据二次破坏，影响恢复效果。

怎样恢复shift delete删除的文件：

这种简单的逻辑删除，我们可以通过迷你兔数据恢复工具来解决。在迷你兔数据恢复软件提供的删除恢复、格式化恢复、硬盘恢复、移动存储设备恢复和深度恢复五个功能模块中，删除恢复可以恢复被误删的文件和文件夹，并且软件扫描迅速，比起人工恢复节约了不少时间。迷你兔在操作上也秉持着简单易懂的原则，电脑小白也能轻易上手，总的来说，恢复shift delete删除的文件一共只有三个步骤。

首先，运行迷你兔数据恢复工具，选择“删除恢复”；

然后，选择丢失文件的磁盘进行扫描，如：文件删除前保存在D盘，就选择D盘扫描；

最后，迷你兔扫描结束，在扫描到的丢失数据里面，选择需要恢复的数据，保存在安全路径之中就可以了。

我家里的个人电脑上有两块硬盘，主盘前年购买，从盘五年前购买，以前一直使用没有问题，也没有坏道，可就在昨天，我那个使用了五年时间的硬盘忽然出现了故障，系统启动后无法读取从盘文件，看不到硬盘，重启进入BOIS，只能看到一块硬盘，另一块看不到。然后关机，再进入BIOS又可以看到两块硬盘，然后操作系统启动后又找不到另一块硬盘了。　　我使用一些磁盘工具进行测试，发现磁盘工具读其他扇区正常，但是读分区表附近的扇区，就会出现死锁，然后系统就不认第二硬盘。　　这个损坏的硬盘有两个分区，1T容量，一个分区40G，剩余接近900G的容量为第二分区，绝大多数数据文件放在第二分区里，并且基本已经装满了硬盘，如果丢失的话，将会损失大量的数据。经过之前的测试，我判断是第二硬盘分区表附近的磁道坏了，磁头读过去就会出现故障。由于大部分数据在第二分区，因此数据内容估计没有受到损坏，还是有可能恢复的。　　这种硬盘损坏是我头一次遇到，一开始我尝试将硬盘数据复制到其他硬盘，经过几次操作，发现无法将硬盘中的文件复制出来，只要将硬盘接入，一读分区表就会不认盘。　　我只好尝试不再修复硬盘，而是将硬盘数据拷出。我手头上正好有一个同样大小的新硬盘，于是我考虑将整个硬盘进行对拷。一开始我使用Ghost进行硬盘复制，结果不但没复制成功，硬盘的分区反而丢失了。看来用Ghost修复硬盘太不靠谱了。　　经过了一次失败，我开始选用另一个工具：DiskGenius磁盘工具，使用其“扇区拷贝”功能对所有扇区进行复制，这个功能有一个不错的特点，就是支持“逆向复制”，可以从后往前拷贝，这对于我目前这种硬盘损坏情况非常适合。拷贝了5、6个小时，终于在95%的附近拷贝死锁，又不认硬盘了。尽管如此，我相信绝大多数数据内容都已经复制过去了。

 　　重新启动之后，使用DiskGenius的查找丢失分区功能进行分区查找，但是只找到一个分区，另一个没找到，只用查找丢失文件功能，终于找到了硬盘里数万个文件，然后将其复制出来，在未恢复分区的情况下，可以找到文件目录，但文件只能恢复开始的一小部分，大小都是小于64K，数据内容都是错的，大文件都打不开。看来必须恢复第二分区才能进行文件恢复操作。　　原有分区无法保存到损坏的硬盘里，而且一复制就不认盘，导致硬盘开头的数据无法复制，因此我只好另想办法，在新硬盘里手动建立分区。　　根据旧硬盘的分区大小和分区数据，我在新的硬盘里，手动建立两个和原有硬盘完全相同的分区，起始柱面、磁头、扇区、终止柱面等参数应该和原有硬盘完全相同。之后使用DiskGenius的“已删除或格式化后的文件恢复”功能，寻找丢失文件，这时候再将里面的大文件复制出来，发现大文件里的数据都是正常的，ZIP等格式也正确，图片显示正常，看来这次恢复是正常了。　　接下来的操作就简单而耗时了，在电脑接上一个移动硬盘，在DiskGenius里全选被恢复的文件，然后将其复制到移动硬盘里就可以正常恢复，估计恢复时间需要6、7个小时。　　最终结果，第二分区的数据基本上被完全恢复，第一分区没有找回，因为第一分区保存的是操作系统，因此没有重要数据，不恢复也无所谓。　　我浪费了2天时间来恢复硬盘数据，使用了原硬盘两倍的存储空间来进行恢复操作，如果我当初能花1、2个小时对硬盘数据进行备份，那么就不会有这么多的时间浪费。还好这2天时间是值得的，因为数据已经完全恢复。　　总结：就算硬盘的日常使用与维护再好，时间长了都有可能产生坏道，一旦硬盘出现了坏道，不必惊慌，如果硬盘上有重要文件，需要将硬盘的数据进行恢复。对于损坏的硬盘，切勿进行写操作，例如安装软件、操作系统、重新分区、切勿磁盘整理等操作，硬盘恢复软件不要直接在故障盘上操作，而要在另一个磁盘上运行。数据恢复需要更多存储空间，因此要准备好原有硬盘两倍左右的存储空间进行数据恢复。　　此外，数据文件和系统软件、应用软件要分开，操作系统、应用软件都安装在一个盘，数据文件放在另一个盘，这样，进行数据恢复的时候，只需要专注恢复数据文件即可，操作系统和其他软件可以不去恢复，而采取重新安装的方法。　　举例来说，对于Windows 7操作系统，将操作系统安装在C盘，点击桌面用户的文件夹，右键点击里面的“我的文档”、“我的图片”、“我的音乐”等图标，在“属性”-“位置”里，将其修改到D盘或其他硬盘，这样，即使整个C盘被格式化，用户的文件也不会丢失。　　一个重要的教训：硬盘使用超过了四年，就绝对不要在硬盘上保存重要的文件。

【存储数据恢复背景介绍】

某公司的netAPP存储设备，因为实习生在操作过程中的误操作导致存储内部分重要数据被删除，该存储采用的是WAFL文件系统，底层是多块硬盘组成的raid阵列。下面小编将为大家详细介绍该案例的数据恢复过程，同时该数据恢复方法同样适用于netAPP其他型号存储的误删除数据的恢复。

【存储数据误删除恢复方法】

对存储设备的原始数据进行镜像备份，这样做的目的是为了在数据恢复过程中对镜像数据进行分析与恢复，保留用户的存储设备原始状态，以免因数据恢复工作人员的操作对原始数据进行更改或覆盖，数据备份对非专业操作者更为重要，一旦原始数据遭覆盖或其他二次破坏，即使专业人员也很难甚至无法再进行数据恢复。对存储内的原始数据进行备份完成后就可以在备份文件中对数据进行分析了，通常数据恢复工作中需要对磁盘镜像的底层数据进行二进制的额分析，获得该存储中数据分布的基本情况，得到raid基本信息（分析的方法与所有raid数据恢复时的分析方法一样，这里不做过多描述）。根据数据的分布情况计算分析出raid基本信息，然后使用我们研发的一款自用的虚拟raid控制器（该自用产品主要用于辅助工程师进行数据恢复使用，目前并未对外销售，可选择市面上常见的其他数据恢复工具代替）重组出一个raid阵列。重组raid阵列后接下来就可以重构逻辑卷了，在重组完的Raid基础之上进行Storage Pool的重构，并导出数据丢失的逻辑卷。此时基础工作已经差不多完成了，可以对WAFL文件系统进行测试了，对NetApp存储进行底层WAFL文件系统差异化测试，并分析差异区域的规则。可以手动编写一个WAFL文件系统的解析程序，借助于这个解析程序对数据丢失的卷进行文件系统解析。继续对删除文件的节点索引信息进行分析，编写程序自动解析杉树文件的索引、自动解析删除节点进而恢复删除数据。如果数据恢复工作顺利的话做到这一步就可以验证数据了。如果数据不全或其他新问题出现则重复上述数据恢复步骤。

【netAPP存储数据恢复结果】

在本次案例中，由于客户的存储设备误删除数据后没有写入操作，原始数据保存完整，数据100%恢复。

故障描述：

5块2T硬盘组建RAID5，划分LUN供windows服务器使用。在windows服务器内装有Sql Server2008数据库。存储空间内共有三个逻辑分区，大小分别为500G、800G、2.3T。数据库文件丢失，主要涉及五个数据库，表个数约为6000个左右。丢失原因未知，且不能确定数据存储位置。三个数据库的大小分别为8G、15G、20G。在文件丢失后服务器仍处于开机状态，但并未写入大量数据。

初检流程：

1、使用RAID信息及内部数据块信息重组RAID。

2、提取LUN内三个分区镜像。

3、扫描文件系统内丢失文件，未找到被删除数据库文件。

4、初检结果为数据库文件丢失，通过文件系统角度无法恢复。

恢复流程：

1、制定恢复方案。在数据库文件被删除且判定为无法恢复文件后，只能通过扫描数据页，并提取页内记录的方式进行恢复。

2、使用北亚自主编数据页扫描程序扫描分区内数据页并提取。在分别扫描两个分区镜像后发现500G系统盘内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页个数较多。暂定此分区为数据库文件存储空间。

3、重组系统表。Sql Server数据库使用系统表来管理所有用户表，在这些系统表内记录了各表的列数、数据类型及约束信息等。解析系统表过程中发现提取出的数据页内系统表损坏，无法正常读取信息。在与客户沟通后得知有备份文件，且备份完成后没有大量改动表结构，系统表可用。

4、还原备份。

5、分别提取三个库中各表表结构信息

6、解析表结构脚本。将各表的列信息存入数据库内便于后续使用。

7、解析系统表获取用户表id信息、关联表结构与数据页。（为保护客户隐私，后续步骤涉及用户表表名及数据页内数据部分均未截图）

8、新建数据库，使用北亚自主编写软件解析记录并导入到恢复环境内。

9、整理恢复结果。在此分区内除数据库文件外还存有备份文件若干，所以在导出记录后可能存在重复数据，必须去重。编写SQL存储过程进行去重。

10、客户验证数据。客户在查验过数据后表示数据可以接受，移交数据到客户存储设备，恢复成功。

恢复硬盘数据其实并不是一项复杂的工程，除非是硬盘磁头损坏，需要开盘这类原因，一般情况下想要恢复硬盘数据也十分简单，那要如何做呢？

第一步，打开迷你兔数据恢复工具，选择【硬盘恢复】功能并点击进入

第二步，进入功能页面后，选择需要恢复的硬盘分区，进行完全扫描

第三步，完全扫描结束后，在软件扫描到的丢失数据列表里手动勾选需要恢复的数据，然后保存在安全的分区之中，硬盘数据就恢复出来了。

数据恢复有没有简易方案？

IT工程师一般都知道如何操作和使用文件和目录。但是，对于系统如何构建出、抽象出文件和目录，一般就不熟悉了。至于更下层的概念，可能大家知道最多的就是驱动了。所以，为了规避这点，可行的简易方案之一，就是以黑箱方式使用testdisk等工具，在我们在对底层了解不多甚至一无所知的情况下，进行数据恢复（商业工具，恢复效果估计更好，当然商业工具的价格也更好）。但是，对于工程师而言，多数时候，仅仅以黑箱方式依赖某些工具进行数据恢复是不够的。

数据恢复，经常是突发事故响应中关键而又耗时的一步。多数情况下，工程师往往并非专司数据恢复，操作环境往往是生产环境，趁手工具难以部署，执行操作要遵循种种约束，加之业务中断的压力。这种情形下，工程师很可能还需要推定数据恢复的结果/耗时等信息，提供数据供决策者使用。很明显，如果你准备考验一下自己的细致、耐心、知识和技能，数据恢复将是个不错的课题。当然，有一点是明确的，只是以黑箱方式使用testdisk等工具进行数据恢复，解决以上问题是不可能的。那么，有没有其他简易方案呢？

这里，我们以一个实际的case为例，讨论一下，在只使用UNIX常见工具（dd/grep/strace等）的情况下，如何简单、快捷的恢复数据。

预先准备

工具

我们要用到以下工具

功能

示例

bc

计算器

echo 'ibase=2^3;i=0107000;ibase=2^3+2;i/512' | bc -l

dd

检查或者拷贝磁盘/分区的内容，可以是几个扇区，也可以是几个字节

dd if=/dev/sdb bs=1 count=64 skip=64 2>/dev/null | od -v -tx1

grep

搜索制定字符串

od

把二进制内容以ASCII或者16进制显示出来，搭配dd使用可以代替二进制编辑器

strace

追踪应用的执行路径和对数据处理的流程

strace ps

排查和诊断就是数据处理

如果对数据处理了解不多，请参考OSEMN

obtaining data/获取数据

crubbing data/清洗数据

exploring data/探索数据

modeling data/建模数据

interpreting data/解释数据

测试环境

使用Virtualbox，基于CentOS/Fedora/debian/Ubuntu搭建Linux实验环境。只需要学会strace工具和如下系统调用，就足以追踪系统如何处理诸如LVM物理卷元数据这样过的问题。

name

open

打开一个文件，返回一个文件描述符供后续读写操作使用

dup/dup2

复制文件描述符

lseek

将读写指针移动到指定位置，后续操作从此指定位置读写

close

关闭文件描述符

read

读操作

数据恢复的原理和流程

什么是元数据？

我们以大家都熟悉的磁盘作为存储设备的例子。

现代操作系统都会在磁盘上建立多个分层结构来管理和控制磁盘。比如，磁盘分区，分区上建立物理卷，物理卷上建立卷组，卷组上建立逻辑卷，逻辑卷上建立文件系统，就是这样的一个例子。如果你不熟悉LVM，请参考Logical Volume Manager。

这些分层的结构都是很类似的。以磁盘分区为例。所谓分区，以大家最为熟悉的MBR: Master Boot Record结构为例。其实是第一个扇区记录了各个分区的起始扇区，大小和类型。系统需要时，比如启动过程中，系统只要从磁盘的第一个扇区读取这些数据即能拿到各个分区的数据。

具体看看分区的数据结构。以fdisk为例，分区的数据结构定义为

struct dos_partition { unsigned char boot_ind;

我们看看具体分区的例子，验证一下数据结构

分区使得磁盘上的扇区有了差别。第一个扇区（其实其编号是0），因分区数据记录其上而扮演特殊角色。明显，对系统而言，管理和操作分区实际上就是读写第一扇区上的对应记录而已。

类似分区信息这种系统用以管理某层资源的数据就是元数据。

系统在磁盘上建立的各个分层结构，都有类似分区结构的数据结构。以LVM结构为例，我们可以把磁盘记录和LVM工具报告的数据做一对比。LVM数据的从第2个扇区开始，卷组数据在第8个扇区中，可以用dd命令提取相关扇区来验证LVM的数据结构。

下面是一份完整的LVM元数据信息，有兴趣者可以逐一清点各个对象。

[root@pusf ~]# pvdisplay;vgdisplay;lvdisplay

元数据和数据：数据损坏分类

系统把磁盘的扇区分成两种来支持分区：第一扇区和所有其他非第一扇区。并且在第一个扇区上记录分区信息，即元数据。而其他非第一扇区则供分区层使用，从磁盘的视角看，其他非第一扇区则是数据部分。我们逐层考察下磁盘、分区和LVM结构

系统启动时，会逐层读取各层元数据，创建各层数据结构。如果某一层元数据损坏或者丢失，那么系统就没有办法完成创建各层数据结构的任务。这种情况下，从客户角度看，很可能就是数据损坏了。比如，如果你把第一个扇区用\0覆盖一遍，那么系统就识别不到分区内容了。当然这种情况下分区层以上的内容，比如物理卷信息，系统也无法处理了。因此，对于数据恢复任务而言，如果元数据损坏，则修复元数据总是必须的，而且往往是第一步。

当然，如果数据损坏了，即使元数据完好无缺，那么数据也是损坏了。比如，你误删了一个文件，那么，分区结构再完好对于文件被删也于事无补。

基于以上分析，我们可以把数据损坏简单分三类类：元数据损坏、数据损坏或者前面两种损坏类型的混合型损坏。

元数据修复可以简易处理

以基于磁盘的分区、LVM以及文件系统为例。分层结构的数据格式都有严格的格式（比如分区的数据结构就是一个C的struct），出现位置也固定（有关分区的元数据记录在第一个扇区的446～462字节之间），而且这些数据结构往往都带有魔数(比如，分区的类型83)，而且常用的分层结构，也不外乎分区、LVM以及文件系统等几种。因此，对于元数据以及系统如何处理元数据，我们都容易追踪和检查。因此，可以预期，修复元数据，有简易方案。

原理

如果有数据损坏，那么除非有日志、备份，或者数据本身有逻辑可供使用，否则数据是不能恢复了。比如，通常的文件删除操作，系统只是解除了文件名称和文件内容相关间的联系而已。文件本身的内容还是记录再磁盘上。这种情况下，只要重建文件名称和文件内容间的联系即可恢复文件。

相对而言，简单情形的是元数据损坏。如果只是元数据损坏，而且我们知道正确的元数据。因为元数据操作，不会触及数据部分，因此，我们只要重建元数据部分即可恢复数据。如果涉及到多层，则逐层恢复即可。以分区丢失为例。

比如我们有一块数据盘，整盘我们只是用fdisk分了一个区，现在分区丢失了。这种情形下，只要用fdsik，按照默认情形，重新分区就能恢复分区。

就这种情形，我们给出一个可用的分析流程。

症状和初步排查

症状

客户反馈

降配重启后，系统无法启动

排查发现客户一逻辑卷无法挂载导致重启失败。在/etc/fstab中注释掉逻辑卷的挂载配置，系统启动成功。

但是客户的逻辑卷上有重要数据。此逻辑卷在数据盘上，数据盘大小是2TB。此磁盘全部2TB全部分配给一个分区，此分区上创建有LVM结构。

分区数据如下

[root@localhost ~]# fdisk -l -u /dev/vdbDisk /dev/vdb: 2199.0 GB, 2199023255552 bytes

初步排查

首先确定分区上是否有数据，通过查看一些扇区，我们就会有很大的概率确认这一点。当然也可以逐扇区确认。

逐扇区确认，可以用如下命令办理。假设磁盘是/dev/vdb。

max_sector_to_check=nrsectorfor i in $(seq 0 ${max_sector_to_check});do dd if=/dev/vdb bs=512 count=1 skip=${i} 2>/dev/null | sha256sum;done | sort -n | uniq;

当然，也可以通过抽样检查来确认。这种方法通常是检查磁盘分区的前面一部分扇区。比如，下面的例子，通过检查前面几十个扇区，我们可以确认磁盘上确有数据。

[root@localhost ~]# dd if=/dev/vdb1 bs=512 count=60 2>/dev/null | od -tx10000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0007000 f9 80 00 00 f9 80 01 00 f9 80 02 00 f9 80 03 000007020 f9 80 04 00 f9 80 0c 00 f9 80 0d 00 f9 80 18 000007040 f9 80 28 00 f9 80 3e 00 f9 80 79 00 f9 80 ab 000007060 f9 80 38 01 f9 80 6c 01 f9 80 45 04 f9 80 b0 040007100 f9 80 1a 06 f9 80 d0 0c f9 80 84 1e 00 00 00 000007120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0017000 fa 80 00 00 fa 80 01 00 fa 80 02 00 fa 80 03 000017020 fa 80 04 00 fa 80 0c 00 fa 80 0d 00 fa 80 18 000017040 fa 80 28 00 fa 80 3e 00 fa 80 79 00 fa 80 ab 000017060 fa 80 38 01 fa 80 6c 01 fa 80 45 04 fa 80 b0 040017100 fa 80 1a 06 fa 80 d0 0c fa 80 84 1e 00 00 00 000017120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0027000 fb 80 00 00 fb 80 01 00 fb 80 02 00 fb 80 03 000027020 fb 80 04 00 fb 80 0c 00 fb 80 0d 00 fb 80 18 000027040 fb 80 28 00 fb 80 3e 00 fb 80 79 00 fb 80 ab 000027060 fb 80 38 01 fb 80 6c 01 fb 80 45 04 fb 80 b0 040027100 fb 80 1a 06 fb 80 d0 0c fb 80 84 1e 00 00 00 000027120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0037000 fc 80 00 00 fc 80 01 00 fc 80 02 00 fc 80 03 000037020 fc 80 04 00 fc 80 0c 00 fc 80 0d 00 fc 80 18 000037040 fc 80 28 00 fc 80 3e 00 fc 80 79 00 fc 80 ab 000037060 fc 80 38 01 fc 80 6c 01 fc 80 45 04 fc 80 b0 040037100 fc 80 1a 06 fc 80 d0 0c fc 80 84 1e 00 00 00 000037120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0047000 fd 80 00 00 fd 80 01 00 fd 80 02 00 fd 80 03 000047020 fd 80 04 00 fd 80 0c 00 fd 80 0d 00 fd 80 18 000047040 fd 80 28 00 fd 80 3e 00 fd 80 79 00 fd 80 ab 000047060 fd 80 38 01 fd 80 6c 01 fd 80 45 04 fd 80 b0 040047100 fd 80 1a 06 fd 80 d0 0c fd 80 84 1e 00 00 00 000047120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0057000 fe 80 00 00 fe 80 01 00 fe 80 02 00 fe 80 03 000057020 fe 80 04 00 fe 80 0c 00 fe 80 0d 00 fe 80 18 000057040 fe 80 28 00 fe 80 3e 00 fe 80 79 00 fe 80 ab 000057060 fe 80 38 01 fe 80 6c 01 fe 80 45 04 fe 80 b0 040057100 fe 80 1a 06 fe 80 d0 0c fe 80 84 1e 00 00 00 000057120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0067000 ff 80 00 00 ff 80 01 00 ff 80 02 00 ff 80 03 000067020 ff 80 04 00 ff 80 0c 00 ff 80 0d 00 ff 80 18 000067040 ff 80 28 00 ff 80 3e 00 ff 80 79 00 ff 80 ab 000067060 ff 80 38 01 ff 80 6c 01 ff 80 45 04 ff 80 b0 040067100 ff 80 1a 06 ff 80 d0 0c ff 80 84 1e 00 00 00 000067120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0074000[root@localhost ~]#

接下来使用testdisk工具恢复数据。尝试数次，testdisk工具总是在扫描到2%时停滞，处理过程不能继续。

初次恢复尝试

分区还在，但是LVM结构丢失，经检查，由LVM工具链维护的备份数据/etc/lvm/backup/vg_xxxxxx文件还在。因此，这种情形下，按照我们的恢复流程，只要在分区之上，尝试重建LVM和文件系统，应该就可以解决问题。

[root@localhost ~]# pvdisplay /dev/vdb

根据备份数据恢复LVM结构，可以参考Recovering Physical Volume Metadata。可惜的是，我们第一步就折戟沉沙了。

[root@localhost ~]# pvcreate --uuid "X1cHlO-kdFk-RZIM-1L12-qHit-0QA5-C1fZxm" --restorefile /etc/lvm/backup/vg_xxxxxx /dev/vdb1

看样子，分区的数据有些地方出错了。根据上面命令报错的信息，对比LVM的备份数据和分区数据，很快我们就发现了问题。现有分区记录的其拥有的扇区数目，少于其上LVM卷组记录的扇区数量。

问题出在哪里？

因为种种原因，我们不能确认分区信息和LVM备份数据为何不一致。但是，我们可以进一步从磁盘上提取、分析数据。因为有关分区的元数据在（分区在），所以我们进一步检查磁盘上还有没有有关LVM的元数据？这只要使用下面的命令行

dd if=/dev/vdb1 bs=512 count=128 2>/dev/null | od -tc

结果及其结果分析如下

所以，磁盘上还有有关LVM的元数据，但是为什么系统没有凭借这些数据构建出LVM结构呢？我们创建一个测试环境，用strace追踪下系统处理LVM物理卷元数据的执行路径。如下命令即可

strace -s 512 pvdisplay

当然，更好的办法是把strace记录放置到文件中，以备仔细检查

starce -o path_to_strace_log -s 512 -f -ff pvdisplay

我们组合使用strace和grep命令来确认系统默认的LVM物理卷位置。如果你没有耐心分析下面的数据，请跳过直接看后面的截图

strace -o /tmp/pvdisplay-strace.log -s 512 pvdisplaygrep grep -E '^open|^lseek|^read' /tmp/pvdisplay-strace.log

数据清洗结果如下。如果没有耐心分析，请跳过直接看下面的分析截图

[root@localhost ~]# grep -E '^open|^lseek|^read|^close' /tmp/pvdisplay-strace.log

很明显，系统预期LVM元数据是在分区的第8个扇区，但是在需要做数据恢复的磁盘上，LVM的元数据却是在第71个扇区，而分区的起始扇区是2048，因此，LVM数据根本不在分区内。这就是为什么磁盘上还有LVM元数据，系统却没有识别出来LVM的原因。

既然系统是因为有关LVM的元数据所在扇区不对而导致系统无法识别LVM结构，设想通过重新分区，我们把有关LVM元数据调整到分区的第8个扇区。稍加计算，就会发现，只要把分区的起始扇区从第2048个扇区调整到第63个扇区即可。不仅如此，通过调整分区大小，我们同样也解决了磁盘分区扇区数不足的问题

数据恢复

较新的fdisk工具，不允许起始扇区小于2048，因此，我们用parted工具来调整分区的起始扇区。

调整过程是先删掉扇区，而后再创建之。而结果正如我们所预期的，分区调整完成，客户的数据立刻恢复了。物理卷、卷组、逻辑卷、文件系统以及数据，都完好无损。

结语

从处理这个实际case可以看出，如果知道如何识别各层元数据，比�...