linux恢复删除的文件
先介绍下一些文件的基本概念：
· 文件实际上是一个指向inode的链接, inode链接包含了文件的所有属性, 比如权限和所有者, 数据块地址(文件存储在磁盘的这些数据块中). 当你删除(rm)一个文件, 实际删除了指向inode的链接, 并没有删除inode的内容. 进程可能还在使用. 只有当inode的所有链接完全移去, 然后这些数据块将可以写入新的数据.
· proc文件系统可以协助我们恢复数据. 每一个系统上的进程在/proc都有一个目录和自己的名字，里面包含了一个fd(文件描述符)子目录(进程需要打开文件的所有链接). 如果从文件系统中删除一个文件, 此处还有一个inode的引用:
1.第一种方法 lsof
当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。
在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。
大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。
lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。
进程在运行中，接下来我就把/var/log/messages这个文件删掉
shell> rm /var/log/messages
删掉之后，我再来看看这个进程的变化
shell> lsof |grep /var/log/messages
rsyslogd 1737 root 1w REG 8,2 5716123 652638 /var/log/messages (deleted)
大家看到有变化了吧，对比两个之后发现多了(deleted)。要找到这个文件在哪还要看看这个
PID:1737 FD:1 那我们有直接进入/proc/1737/FD/1用ll查看一下
shell> cd /proc/1737/fd/
shell> ll
total 0
lrwx------ 1 root root 64 Dec 2313:000 -> socket:[11442]
l-wx------ 1 root root 64 Dec 2313:001 -> /var/log/messages (deleted)
l-wx------ 1 root root 64 Dec 2313:002 -> /var/log/secure
lr-x------ 1 root root 64 Dec 2313:003 -> /proc/kmsg
l-wx------ 1 root root 64 Dec 2313:004 -> /var/log/maillog
看到了1对应/var/log/messages (deleted），看看文件是不是我们要的文件:
shell> head -51
Nov 1403:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started.
Nov 1403:11:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10"x-pid="1241"x-info="http://www.rsyslog.com"] start
Nov 1403:11:11 localhost kernel: Initializing cgroup subsys cpuset
Nov 1403:11:11 localhost kernel: Initializing cgroup subsys cpu
Nov 1403:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 ([email protected]) (gcc version 4.4.720120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013
对比备份文件：
shell> head -5 /var/log/message_bac
Nov 1403:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started.
Nov 1403:11:11 localhost rsyslogd: [origin software="rsyslogd" swVersion="5.8.10"x-pid="1241"x-info="http://www.rsyslog.com"] start
Nov 1403:11:11 localhost kernel: Initializing cgroup subsys cpuset
Nov 1403:11:11 localhost kernel: Initializing cgroup subsys cpu
Nov 1403:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 ([email protected]) (gcc version 4.4.720120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013
对比发现数据是一样的，恢复
shell> cat 1 > /var/log/messages
对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。
2.第二种方法 extundelete
-
测试误操作删除以下文件
/usr/local/dbdata/gperftools-2.4.tar.gz #文件 /usr/local/dbdata/pcre-8.32 #目录执行误操作：
# rm -rf /usr/local/dbdata/gperftools-2.4.tar.gz /usr/local/dbdata/pcre-8.32 -
将误操作所在分区进行只读保护
如果确定文件被误删，在没有备份的情况下请马上对分区实施写入保护（预防新的写入覆盖误删的块数据，因此权限给只读）：
# mount -o remount,ro /dev/sdb # mount -o remount,ro /usr/local/dbdata/ -
数据恢复工具安装
工具安装部署
官方网站是
http://extundelete.sourceforge.net/，其目前的稳定版本是extundelete-0.2.4.工具下载
# wget https://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.bz2解压安装
依赖包
# yum -y install gcc-c++ e2fsprogs.x86_64 e2fsprogs-devel.x86_64 # tar -jxvf extundelete-0.2.4.tar.bz2 # cd extundelete-0.2.4 # ./configure # make && make install验证安装结果
# extundelete -v -
文件恢复过程
恢复指定文件：
原理：从根节点(inode=2)开始找到被删除文件的i节点，然后recover i节点。
以下是模拟删除gperftools-2.4.tar.gz（文件）和pcre-8.32 （目录）
先检测被删除的文件有哪些：
# extundelete /dev/sdb --inode 2可以看到，有以下两个
gperftools-2.4.tar.gz 15 Deleted pcre-8.32 655361 Deleted注意：恢复过程不要在误删分区进行，谨防inode. block块相互覆盖
先恢复文件（可根据文件名进行恢复）：
# extundelete /dev/sdb --restore-file gperftools-2.4.tar.gz恢复目录（根据目：# extundelete /dev/sdb --restore-directory pcre-8.32
最后会在当前目录下看到一个名为RECOVERED_FILES的目录，在目录里就可以看到被误删除的文件以及目录：
根据上面操作证明extundelete 工具可以实现对误删数据的恢复，而且操作简单。
总结：
-
使用rm一定要谨慎
-
磁盘按照功能进行分区是必要的
-
最少掌握一种数据恢复方式