linux恢复误删数据测试，linux恢复误删

linux恢复误删数据测试，linux恢复误删

在误删了数据我们立马要做的操作：不要做任何写入操作，不要做任何保存操作，把所删数据所在的盘卸载（umount），然后以只读方式挂载（mount -o ro），或者是直接用mount -o remount,ro重新挂载。如果提示“device is busy"类的信息，可以用fuser -k -i /mount_point来杀死所有正在使用这个盘的进程（-i是交互模式，会提示）。因为现在系统自动分区的话一般是只把一个分区挂在/目录下，没法再重新挂载，所以要果断关机， 把硬盘挂在另一个linux系统上进行恢复数据操作。

本例实研环境centos 6.5，要恢复的数据是装unbuntu系统的硬盘的/home/lei下的文件和目录

1、在centos 6.5上安装extundelete。

extundelete可以从ext3和ext4文件系统恢复数据的linux工具
最新版本为0.2.4，从extundelete.sourceforge.net下载
为了支持ext4系统，它依赖e2fsprogs-devel开发包1.41以上版本
（e2fsprogs（也叫做e2fs programs）是一个Ext2（及Ext3/4）文件系统工具集（Ext2 Filesystems Utilities[），它包含了诸如创建、修复、配置、调试ext2文件系统等的标准工具。在不同的linux发行版上它的名字不同）

wget http://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2 下载extundelete
yum list e2fsprogs-devel 版本为1.41.12－18.el6 正好满足需要
yum install e2fsprogs-devel 安装 （它依赖同版本号的libcom_err-devel）
tar -jxvf extundelete-0.2.4.tar.bz2
cd extundelete-0.2.4
./configure 然后报错了，提示让查看config.log，实上不用看，没有安装gcc-c++或者gnu make
yum list gcc-c++ make 显示make 已安装，gcc-c++没有
yum install gcc-c++ 它的依赖文件有一大堆，幸亏有yum
./configure 生成Makefile文件
make 编译 (这里提示了一个警告warning: unused parameter "flags"，应该没有太大问题)
make install 安装
extundelete -v 显示了版本信息，安装成功

2、关机把要恢复数据的盘挂上系统。然后开机，做挂载操作。

（挂载别的硬盘的逻辑卷具体要做的操作些处省略）
mount -o ro /dev/lei-pc/root /mnt # /dev/lei-pc/root是要恢复数据的ubuntu系统的根分区
-o ro 以只读模式挂载

3、开始恢复

extundelete /dev/lei-pc/root --restore-directory /mnt/home/lei

# extundelete [要恢复的设备文件] --restore-directory [要恢复的目录或文件]
但可惜的是出错了，错误信息如下
NOTICE: Extended attributes are not restored.
Loading filesystem metadata … 75 groups loaded.
Loading journal descriptors … 29398 descriptors loaded.
Failed to restore file /mnt/home/lei
Could not find correct inode number past inode 287274.
Try altering the filename to one of the entries listed below.
File name | Inode number | Deleted status
extundelete: Operation not permitted while restoring directory.
extundelete: Operation not permitted when trying to examine filesystem

再试，不指定具体目录，用--restore-all 恢复所有能恢复的文件
extundelete /dev/lei-pc/root --restore-all 
不像上次那样有很多屏幕输出，有希望哦
ls 
看到了RECOVERED_FILES，说不定成功了，赶紧进去看看，发现在里边有很多安装日志之类的文本文件，也有home/lei目录，可是进去没有发现在被我删除的文件。重新试了几次，依然是这样。
恢复失败了。

4、心有不甘，再试

进入ubuntu系统，从网上下了三张图片，防在桌面上的testonemore文件夹里。然后打开终端输入
rm -rf Desktop/testonemore
sudo mount -o remount,ro /dev/lei-pc/root 想要以只读模式挂载根分区，但提示/“ is busy“”，失败了
sudo poweroff
再次把盘挂在centos下，启动centos
这次我没有把/dev/lei-pc/root挂载到/mnt目录下而是直接开始恢复
extundelete /dev/lei-pc/root --restore-all 
cd RECOVERED_FILES 里边依然有很多日志类文件，但找到了home/lei/Desktop目录，里边有一个名为“Untitled Folder”的文件夹，进去一看是我放的那三张图片。也许这次真的成功了

5、测试数据是否已经损坏。

我有同样的三张图片放在/root/testonemore文件夹里，用md5sum看看是不是一样的
md5sum /root/testonemore/pic1.jpg 看到了原文件的md5值
md5sum pic1.jpg 输出的md5值和原文件一样，这些真的恢复成功了。

6、总结

第一次之所以不成功，是可能是因为我在关机的时候依然有一些保存操作，导致数据被覆盖了，而第二次文件夹名改变也应该是同样的原因，文件名和牵引节点号错位了，不过运气比较好，问题不大。
从这次可以看出，不是误删之后立即停止操作就一定能恢复数据，对于硬盘只有一个根分区的系统来说，能不能恢复数据，真的要看运气。

非常麻烦，和分区格式有关。
 

Linux 下的文件一旦被删除，是难以恢复的。尽管删除命令只是在文件节点中作删除标记，并不真正清除文件内容，但是其他用户和一些有写盘动作的进程会很快覆盖这些数据。不过，对于家庭单机使用的Linux ，或者误删文件后及时补救，还是可以恢复的。

1 、Ext2文件系统结构的简单介绍

在Linux 所用的Ext2文件系统中，文件是以块为单位存储的，默认情况下每个块的大小是1K，不同的块以块号区分。每个文件还有一个节点，节点中包含有文件所有者，读写权限，文件类型等信息。对于一个小于12个块的文件，在节点中直接存储文件数据块的块号。如果文件大于12个块，那么节点在12个块号之后存储一个间接块的块号，在这个间接块号所对应的块中，存储有256 个文件数据块的块号（Ext2fs中每个块号占用4 字节，这样一个块中所能存储的块号就是1024/4=256）。如果有更大的文件，那么还会在节点中出现二级间接块和三级间接块。

2 、恢复被误删文件的方法

大多数Linux 发行版都提供一个debugfs 工具，可以用来对Ext2文件系统进行编辑操作。不过在使用这个工具之前，还有一些工作要做。

首先以只读方式重新挂载被误删的文件所在分区。使用如下命令：（假设文件在/usr分区）

mount –r –n –o remount /usr -r 表示只读方式挂载；-n表示不写入/etc/mtab，如果是恢复/etc上的文件，就加上这个参数。如果系统说xxx partion busy，可以用fuser 命令查看一下是哪些进程使用这个分区上的文件：

fuser –v –m /usr

如果没有什么重要的进程，用以下命令停掉它们：

fuser -k–v –m /usr

然后就可以重新挂载这些文件系统了。

如果是把所有的文件统一安装在一个大的/ 分区当中，可以在boot提示符下用linux single进入单用户模式，尽量减少系统进程向硬盘写入数据的机会，要不干脆把硬盘挂在别的机器上。另外，恢复出来的数据不要写到/ 上面，避免破坏那些有用的数据。如果机器上有dos/windows ，可以写到这些分区上面：

mount –r –n /dev/hda1 /mnt/had

然后就可以执行debugfs ：（假设Linux 在 /dev/hda5）

#debugfs /dev/hda5

就会出现debugfs 提示符debugfs ：

使用lsdel 命令可以列出很多被删除的文件的信息：

debugfs ：lsdel

debugfs ： 2692 deleted inodes found.

Inode Owner Mode Size Blocks Time deleted

164821 0 100600 8192 1/ 1 Sun May 13 19 ：22：46 2001

…………………………………………………………

36137 0 100644 4 1/ 1 Tue Apr 24 10 ：11：15 2001

196829 0 100644 149500 38/ 38 Mon May 27 13 ......余下全文>>