一次数据恢复经历

http://extundelete.sourceforge.net/options.html

误删除/usr/share目录
因此考虑恢复目录
过程如下:
1.选用extundelete软件来进行恢复,源码编译安装
[[email protected] src]# bunzip2 extundelete-0.2.4.tar.bz2
[[email protected] src]# tar xf extundelete-0.2.4.tar
tar -xjf extundelete-0.2.0.tar.bz2
下面这是第一个警告,不予理睬。
[[email protected] extundelete-0.2.4]# less README
WARNING: terminal is not fully functional

必须先umount要恢复文件的分区或者把分区改为只读模式,命令:mount –o remout,ro 分区(例如:dev/hda1)或者
mount -n -r -o remount /db  最好尽快将所在分区修改为只读方式,防止数据被覆盖使用。

[[email protected] extundelete-0.2.4]# yum install gcc-c++
Traceback (most recent call last):
  File "/usr/bin/yum", line 28, in <module>
    import yummain
ImportError: No module named yummain

[[email protected] extundelete-0.2.4]# ./configure
Configuring extundelete 0.2.4
configure: error: in `/usr/local/src/extundelete-0.2.4‘:
configure: error: C++ compiler cannot create executables
See `config.log‘ for more details

[[email protected] src]# rpm -ivh libstdc++-devel-4.4.7-11.el6.x86_64.rpm libstdc++-4.4.7-11.el6.x86_64.rpm gcc-c++-4.4.7-11.el6.x86_64.rpm --replacefiles

[[email protected] extundelete-0.2.4]# ./configure
Configuring extundelete 0.2.4
configure: error: Can‘t find ext2fs library

[[email protected] packages]# ll
total 964
-rw-r--r--. 1 root root 566700 2014-10-18 04:00 e2fsprogs-1.41.12-21.el6.x86_64.rpm
-rw-r--r--. 1 root root 164100 2014-10-18 04:02 e2fsprogs-devel-1.41.12-21.el6.x86_64.rpm
-rw-r--r--. 1 root root 123728 2014-10-18 04:01 e2fsprogs-libs-1.41.12-21.el6.x86_64.rpm
-rw-r--r--. 1 root root  38088 2014-10-18 04:02 libcom_err-1.41.12-21.el6.x86_64.rpm
-rw-r--r--. 1 root root  33232 2014-10-18 04:01 libcom_err-devel-1.41.12-21.el6.x86_64.rpm
-rw-r--r--. 1 root root  42468 2014-10-18 04:01 libss-1.41.12-21.el6.x86_64.rpm
[[email protected] packages]# rpm -ivh * --replacefiles
Preparing...                ########################################### [100%]
        package libcom_err-1.41.12-21.el6.x86_64 is already installed
        package e2fsprogs-libs-1.41.12-21.el6.x86_64 is already installed
        package libcom_err-devel-1.41.12-21.el6.x86_64 is already installed
        package libss-1.41.12-21.el6.x86_64 is already installed
        package e2fsprogs-1.41.12-21.el6.x86_64 is already installed
[[email protected] packages]# rpm -ivh e2fsprogs-devel-1.41.12-21.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:e2fsprogs-devel        ########################################### [100%]
[[email protected] packages]# cd ../extundelete-0.2.4
[[email protected] extundelete-0.2.4]# ./configure
Configuring extundelete 0.2.4
Writing generated files to disk

[[email protected] extundelete-0.2.4]# make
make -s all-recursive
Making all in src
extundelete.cc:571: warning: unused parameter
You have new mail in /var/spool/mail/root
[[email protected] extundelete-0.2.4]# make install
Making install in src
  /usr/bin/install -c extundelete ‘/usr/local/bin‘

[[email protected] extundelete-0.2.4]# extundelete /dev/mapper/VolGroup-lv_root  --inode 651608

[[email protected] extundelete-0.2.4]# extundelete /dev/mapper/VolGroup-lv_root --restore-directory /usr/share
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible.  You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)
y
Loading filesystem metadata ... 117 groups loaded.
Loading journal descriptors ... 30051 descriptors loaded.
Searching for recoverable inodes in directory /usr/share ...
1087 recoverable inodes found.
Looking through the directory structure for deleted files ...
Unable to restore inode 656184 (usr/share/policycoreutils-2.0.83): Space has been reallocated.
Unable to restore inode 656716 (usr/share/fuse-2.8.3): Space has been reallocated.
797 recoverable inodes still lost.

[[email protected] usr]# pwd
/usr
[[email protected] usr]# cp  -r /usr/local/src/extundelete-0.2.4/RECOVERED_FILES/usr/share/ ./

拷贝其它系统中的/usr/share/yum-plugins和/usr/share/yum-cli到本系统下,yum就可以用了
[[email protected] share]# yum search wget
Traceback (most recent call last):
  File "/usr/bin/yum", line 28, in <module>
    import yummain
ImportError: No module named yummain
[[email protected] share]# cd yum-
yum-3.2.29/                      yum-plugin-fastestmirror-1.1.30/

[[email protected] src]# cd /usr/share/yum-
yum-3.2.29/                      yum-cli/                         yum-plugin-fastestmirror-1.1.30/ yum-plugins/

有时候删除了大量的数据量,其中很多数据都是没用的,我们仅需要恢复其中的一部分数据,此时,如果采用恢复全部数据的办法,不但耗时,而且浪费资源,在这种情况下,就需要采用另外的一种恢复机制有选择地恢复,extundelete提供了“—after”“和”--before“参数,可以通过指定某个时间段,进而只恢复这个时间段内的数据。
[[email protected] mnt]# extundelete  --after 1379146740 --restore-all /dev/sdc1

在数据被误删除后,第一时间要做的是卸载被删除数据所在的磁盘或磁盘分区,如果是系统根分区的数据遭到误删除,就需要将系统进入单用户,并且将根分区以只读模式挂载。这样做的原因很简单,因为将文件删除后,仅仅是将文件的inode结点中的扇区指针清零,实际文件还存储在磁盘上,如果磁盘以读写模式挂载,这些已删除的文件的数据块就可能被操作系统重新分配出去,在这些数据块被新的数据覆盖后,这些数据就真的丢失了,恢复工具也回力无天。所以,以只读模式挂载磁盘可以尽量降低数据块中数据被覆盖的风险,以提高恢复数据成功的比率。

2.卸载磁盘分区
在将数据误删除后,立刻需要做的就是卸载这块磁盘分区:
[[email protected] data]#cd /mnt
[[email protected] mnt]# umount /data
3.查询可恢复的数据信息
通过extundelete命令可以查询/dev/sdc1分区可恢复的数据信息:
[[email protected] /]# extundelete  /dev/sdc1  --inode 2

在Linux下,基于开源的数据恢复工具有很多,常见的有debugfs、R-Linux、ext3grep、extundelete等,比较常用的有ext3grep和extundelete,这两个工具的恢复原理基本一样,只是extundelete功能更加强大,本文重点介绍extundelete的使用。

extundelete的恢复原理

在介绍使用extundelete进行恢复数据之前,简单介绍下关于inode的知识。在Linux下可以通过“ls –id”命令来查看某个文件或者目录的inode值,例如查看根目录的inode值,可以输入:
[[email protected] ~]# ls -id  /
2 /
由此可知,根目录的inode值为2。
在利用extundelete恢复文件时并不依赖特定文件格式,首先extundelete会通过文件系统的inode信息(根目录的inode一般为2)来获得当前文件系统下所有文件的信息,包括存在的和已经删除的文件,这些信息包括文件名和inode。然后利用inode信息结合日志去查询该inode所在的block位置,包括直接块,间接块等信息。最后利用dd命令将这些信息备份出来,从而恢复数据文件。

时间: 2024-08-28 10:22:12

一次数据恢复经历的相关文章

磁盘阵列进行数据恢复实例

在数据恢复中,我们经常会遇到阵列数据恢复,有些阵列数据恢复是比较简单的,像RAID1.RAID0.RAID5等简单结构的阵列数据恢复,这种阵列数据恢复在上海天盾数据恢复中心是极为简单的数据恢复,恢复率几乎可以达到99%,可是有时候,我们也会遇见比较复杂的复合型阵列数据恢复问题,上海天盾数据恢复中心和大家分享一组复杂的阵列数据恢复实例. 以我所在的上海天盾数据恢复中心前几天遇到的RAID5+0阵列数据恢复来说,不仅在结构上有别于以往的RAID5阵列,而且在阵列数据恢复过程中也有很大区别,但经过我们

实例磁盘阵列数据恢复方法

在RAID阵列数据恢复中,我们经常会遇到诸如RAID1.RAID0.RAID5等简单结构的阵列数据恢复,这类阵列数据恢复一般难度不大,数据恢复成功率也比较高.但当遇到复杂结构的阵列类型,如复合型阵列结构RAID0+1.RAID1+0.RAID5+0.RAID3+0.RAID6.RAID5E.RAID5EE等,这类阵列数据恢复难度相对较大. 如我所在的上海天盾数据恢复中心曾遇到过一组4个硬盘的RAID0,并不是简单的块串联,而是很长的块组合后才有规律:而RAID5类型也有由HP RAID5双循环的

我亲身经历的一起raid数据恢复及回迁过程

故障发生在两块盘组成的一个raid0上,其中的一块盘亮黄灯,被raid卡踢出后,raid崩溃,下面就把当时抢救数据的整个过程进行介绍. 由于硬盘是两块SAS 300G的硬盘,先把硬盘从机器中拔出来,然后通过SAS HBA的方式直连到win的环境下,并在磁盘管理中将硬盘标记为脱机状态,以保证操作过程中是只读的,保护原始数据的安全. 在将两个硬盘底层所有扇区都镜像出来后,通过文件系统分析盘序和条带大小,使用软件虚拟重组的方式将原始raid环境搭起来后,再进一步解析ntfs文件系统后终于看到了数据,这

android数据恢复

很多人都有在使用手机时误删数据的经历,比方说和女朋友分手后把之前一起玩耍的影像资料删除了,结果没过几天又复合了,某天女朋友想和你一起回忆某个温馨时刻,这时候拿不出照片或视频来会非常尴尬.为了避免这类人(Xi)间(Wen)惨(Le)剧(Jian)发生,很有必要掌握一下数据恢复技术. 传统的数据恢复往往借助软件即可完成,例如Easy Recovery,Recuva之类.但这类软件对新的安卓系统手机往往无能为力了,因为从几年前开始,大部分手机生产厂商用"媒体设备"MTP模式替代了大容量USB

数据备份与数据恢复产品——程序员的必备品

转载请注明出处! 原文链接:http://blog.csdn.net/zgyulongfei/article/details/37955857 小学有一篇课文叫做<亡羊补牢>,相信大家都还记得,这个故事告诉我们:在出了问题之后马上想办法补救可以防止情况恶化受到更严重的损失.谚语也有说"小洞不补,大洞吃苦",说的是遇到小问题要马上补救否则会酿成大祸.在信息安全领域里,数据丢失后进行亡羊补牢的方法是:数据恢复. 诗经<诗经·豳风·鸱鸮>有句:"迨天之未阴雨

北亚关于HP EVA4400/6400/8400/P6000的数据恢复解决方案

[引言]本文档建立在针对HP EVA的大量测试性研究基础上,所有的细节几乎均为对EVA的破译型研究,目前全球范围内尚未发现类似资料,故可能表述方式和结论并不精确,仅为参考之用.我们公司为研究HP EVA系列算法,花费了大量的人力物力,目前应为全国唯一的研究此项技术的公司,转载请注明来源. [前因]HP EVA4400/6400/8400因接近退役,已进入高故障区间,用户往往会认为花费几十万甚至上百万购买的eva系列应该是非常稳定的,但实际上无论多么昂贵的存储设备,使用的磁盘是相同或相似的.正如e

如何正确的对安卓手机进行数据恢复?

摘要: 很多人觉得数据恢复就是拿工具扫一扫,这种想法是非常错误的.想干好一件事,绝不是仅仅机械性的重复固有动作,必须要加入个人的思考.比如对安卓手机的数据恢复,你真的会吗? 0×00 背景介绍 很多人都有在使用手机时误删数据的经历,比方说和女朋友分手后把之前一起玩耍的影像资料删除了,结果没过几天又复合了,某天女朋友想和你一起回忆某个温馨时刻,这时候拿不出照片或视频来会非常尴尬. 很多人觉得数据恢复就是拿工具扫一扫,这种想法是非常错误的.想干好一件事,绝不是仅仅机械性的重复固有动作,必须要加入个人

HP EVA4400/6400/8400/P6000数据恢复方法归类整理

[引言] 本文档建立在针对HP EVA的大量测试性研究基础上,所有的细节几乎均为对EVA的破译型研究,目前全球范围内尚未发现类似资料,故可能表述方式和结论并不精确,仅为参考之用. 我们公司为研究HP EVA系列算法,花费了大量的人力物力,目前应为全国唯一的研究此项技术的公司,转载请注明来源. [前因] HP EVA4400/6400/8400因接近退役,已进入高故障区间,用户往往会认为花费几十万甚至上百万购买的eva系列应该是非常稳定的,但实际上无论多么昂贵的存储设备,使用的磁盘是相同或相似的.

北京某公司NetApp存储虚拟机数据恢复案例

存储环境部署及存储数据恢复故障的起因:某公司的NetApp FAS-8200存储,使用96块磁盘组建两组存储池,存储池互为镜像.存储池内划分卷并映射到ESXI作为数据存储使用,卷内虚拟机数量约300+.在操作过程中由于未知原因导致卷丢失,卷内虚拟机不可访问.该公司的管理员先进对存储进行了简单的检查和数据恢复但是没有成功,由于存储内有公司重要数据,管理员不敢妄动,只好联系北京的存储数据恢复公司进行专业数据恢复. 一.数据恢复备份 为防止对客户原始磁盘内数据造成破坏,首先分别对各磁盘进行镜像拷贝(在