Linux下rm误删除文件的三种恢复方法

吾爱主题 阅读:218 2024-04-05 15:06:57 评论:0

对于rm,很多人都有惨痛的教训。我也遇到一次,一下午写的程序就被rm掉了,幸好只是一个文件,第二天很快又重新写了一遍。但是很多人可能就不像我这么幸运了。本文收集了一些在Linux下恢复rm删除的文件的方法,给大家作为参考。

1.几点建议避免误删

 首先,最好的方法是避免这个问题,以下是几点建议:

  1、rm -rf误操作的后果是可怕的,rm -f也要三思而行,不能轻易使用。

  2、做好数据备份。

  3、用一些策略避免出错:

  提倡在shell下用 TAB 补全,用脚本执行任务,减少出错的机会。或者编写一个脚本,起名rm,在脚本里将真实的rm改为mv ,将删除的都mv到一个指定的目录里面,定期清理。

  那么rm删除的文件还能恢复吗?

  rm的man里面有如下说法:

  请注意,如果使用 rm 来删除文件,通常仍可以将该文件恢复原状。如果想保证该文件的内容无法还原,请考虑使用 shred。

  所以理论上rm删除的文件是还能恢复的。删掉文件其实只是将指向数据块的索引点(information nodes)释放,只要不被覆盖,数据其实还在硬盘上,关键在于找出索引点,然后将其所指数据块内的数据抓出,再保存到另外的分区。在用rm误删除文件后,我们要做的第一件事就是保证不再向误删文件的分区写数据。

2.使用lsof命令恢复

lsof命令用于查看你进程开打的文件,打开文件的进程,进程打开的端口(TCP、UDP)。找回/恢复删除的文件。是十分方便的系统监视工具,因为lsof命令需要访问核心内存和各种文件,所以需要root用户执行。

在linux环境下,任何事物都以文件的形式存在,通过文件不仅仅可以访问常规数据,还可以访问网络连接和硬件。所以如传输控制协议 (TCP) 和用户数据报协议 (UDP) 套接字等,系统在后台都为该应用程序分配了一个文件描述符,无论这个文件的本质如何,该文件描述符为应用程序与基础操作系统之间的交互提供了通用接口。因为应用程序打开文件的描述符列表提供了大量关于这个应用程序本身的信息,因此通过lsof工具能够查看这个列表对系统监测以及排错将是很有帮助的。

1.语法

?
1 lsof(选项)

2.参数

?
1 2 3 4 5 6 7 8 9 10 11 12 -a:列出打开文件存在的进程; -c<进程名>:列出指定进程所打开的文件; -g:列出GID号进程详情; -d<文件号>:列出占用该文件号的进程; +d<目录>:列出目录下被打开的文件; +D<目录>:递归列出目录下被打开的文件; -n<目录>:列出使用NFS的文件; -i<条件>:列出符合条件的进程。(4、6、协议、:端口、 @ip ) -p<进程号>:列出指定进程号所打开的文件; -u:列出UID号进程详情; -h:显示帮助信息; -v:显示版本信息。

3.使用

查看

lsof -i:(端口) 查看这个端口有那些进程在访问,比如22端口

?
1 2 3 4 5 6 7 8 shell> lsof -i:22 COMMAND   PID USER   FD   TYPE DEVICE SIZE /OFF NODE NAME sshd     1939 root    3u  IPv4  12317      0t0  TCP *: ssh (LISTEN) sshd     1939 root    4u  IPv6  12321      0t0  TCP *: ssh (LISTEN) sshd     2790 root    3u  IPv4  15229      0t0  TCP 192.168.178.128: ssh ->192.168.178.1:64601 (ESTABLISHED) sshd     2824 root    3u  IPv4  15528      0t0  TCP 192.168.178.128: ssh ->192.168.178.1:64673 (ESTABLISHED) sshd     2990 root    3u  IPv4  15984      0t0  TCP 192.168.178.128: ssh ->192.168.178.1:64686 (ESTABLISHED) sshd    14695 root    3u  IPv4  39558      0t0  TCP 192.168.178.128: ssh ->192.168.178.1:49662 (ESTABLISHED)

lsof输出各列信息的意义如下:

  • COMMAND:进程的名称
  • PID:进程标识符
  • USER:进程所有者
  • FD:文件描述符,应用程序通过文件描述符识别该文件。如cwd、txt等
  • TYPE:文件类型,如DIR、REG等
  • DEVICE:指定磁盘的名称
  • SIZE:文件的大小
  • NODE:索引节点(文件在磁盘上的标识)
  • NAME:打开文件的确切名称

恢复文件

利用lsof可以恢复一些系统日志,前提是这个进程必须存在。这里就拿最常用的/var/log/messages来举例说明,大家在做测试的时候最好先备份一下。

?
1 2 3 4 #备份 shell> cp /var/log/message /var/log/message_bac shell> lsof | grep /var/log/message rsyslogd   1737      root    1w      REG                8,2   5716123     652638 /var/log/messages

进程在运行中,接下来我就把/var/log/messages这个文件删掉

?
1 shell> rm /var/log/messages

删掉之后,我再来看看这个进程的变化

?
1 2 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查看一下

?
1 2 3 4 5 6 7 8 9 shell> cd /proc/1737/fd/ shell> ll   total 0 lrwx------ 1 root root 64 Dec 23 13:00 0 -> socket:[11442] l-wx------ 1 root root 64 Dec 23 13:00 1 -> /var/log/messages (deleted) l-wx------ 1 root root 64 Dec 23 13:00 2 -> /var/log/secure lr-x------ 1 root root 64 Dec 23 13:00 3 -> /proc/kmsg l-wx------ 1 root root 64 Dec 23 13:00 4 -> /var/log/maillog

看到了1对应/var/log/messages (deleted),看看文件是不是我们要的文件:

?
1 2 3 4 5 6 shell> head -5 1 Nov 14 03:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started. Nov 14 03:11:11 localhost rsyslogd: [origin software= "rsyslogd" swVersion= "5.8.10" x-pid= "1241" x-info= "http://www.rsyslog.com" ] start Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpuset Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpu Nov 14 03:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

对比备份文件:

?
1 2 3 4 5 6 shell> head -5 /var/log/message_bac Nov 14 03:11:11 localhost kernel: imklog 5.8.10, log source = /proc/kmsg started. Nov 14 03:11:11 localhost rsyslogd: [origin software= "rsyslogd" swVersion= "5.8.10" x-pid= "1241" x-info= "http://www.rsyslog.com" ] start Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpuset Nov 14 03:11:11 localhost kernel: Initializing cgroup subsys cpu Nov 14 03:11:11 localhost kernel: Linux version 2.6.32-431.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

对比发现数据是一样的,恢复

?
1 shell> cat 1 > /var/log/messages

再次提醒,恢复前提是这个进程必须存在。

3.使用extundelete工具

extundelete工具安装

?
1 wget https: //nchc .dl.sourceforge.net /project/extundelete/extundelete/0 .2.4 /extundelete-0 .2.4. tar .bz2

解压该文件tar jxvf extundelete-0.2.4.tar.bz2

若报这种错误

?
1 2 3 4 5 [root@docking ~] # tar jxvf extundelete-0.2.4.tar.bz2 tar (child): bzip2 :无法 exec : 没有那个文件或目录 tar (child): Error is not recoverable: exiting now tar : Child returned status 2 tar : Error is not recoverable: exiting now

则使用yum -y install bzip2进行解决

?
1 2 3 4 5 6 7 8 9 10 [root@docking ~] # tar jxvf extundelete-0.2.4.tar.bz2 extundelete-0.2.4/ extundelete-0.2.4 /acinclude .m4 extundelete-0.2.4 /missing extundelete-0.2.4 /autogen .sh extundelete-0.2.4 /aclocal .m4 extundelete-0.2.4 /configure extundelete-0.2.4 /LICENSE extundelete-0.2.4 /README ...................................................
?
1 2 cd  extundelete-0.2.4 . /configure

若这步骤报错

?
1 2 3 4 5 [root@docking extundelete-0.2.4] # ./configure Configuring extundelete 0.2.4 configure: error: in ` /root/extundelete-0 .2.4': configure: error: C++ compiler cannot create executables See `config.log' for more details

则使用yum -y install gcc-c++解决.

若执行上一步仍然报错,

?
1 2 3 [root@docking extundelete-0.2.4] # ./configure Configuring extundelete 0.2.4 configure: error: Can't find ext2fs library

则使用yum -y install e2fsprogs e2fsprogs-devel来解决。
#Ubuntu的解决办法为sudo apt-get install e2fslibs-dev e2fslibs-dev

不出意外的话到这里应该configure能够顺利完成.

?
1 2 3 4 [root@docking extundelete-0.2.4] # ./configure Configuring extundelete 0.2.4 Writing generated files to disk [root@docking extundelete-0.2.4] #

最后make然后 make install

?
1 2 3 4 5 6 7 8 9 10 [root@docking extundelete-0.2.4] # make make -s all-recursive Making all in src extundelete.cc: 在函数‘ext2_ino_t find_inode(ext2_filsys, ext2_filsys, ext2_inode*, std::string, int)'中: extundelete.cc:1272:29: 警告:在 {} 内将‘search_flags '从‘int' 转换为较窄的类型‘ext2_ino_t {aka unsigned int}' [-Wnarrowing]      buf, match_name2, priv, 0};                               ^ [root@docking extundelete-0.2.4] # make install Making install in src    /usr/bin/install -c extundelete '/usr/local/bin'

extundelete安装完成.

扫描误删除的文件:

使用df -lh查看挂载:

?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 taroballs@taroballs-PC:~$ df -lh 文件系统        容量  已用  可用 已用% 挂载点 udev            1.9G     0  1.9G    0% /dev tmpfs           387M  1.8M  385M    1% /run /dev/sda2        92G   61G   26G   71% / tmpfs           1.9G   49M  1.9G    3% /dev/shm tmpfs           5.0M  4.0K  5.0M    1% /run/lock tmpfs           1.9G     0  1.9G    0% /sys/fs/cgroup /dev/sda3       104G   56G   44G   57% /home tmpfs           387M   40K  387M    1% /run/user/1000 /dev/sda4        70G   20G   47G   30% /media/taroballs/d8423f8c-d687-4c03-a7c8-06a7fb57f96d /dev/sdb1       6.8G  4.1G  2.8G   60% /media/taroballs/taroballs /dev/sr0        4.0G  4.0G     0  100% /media/taroballs/2018-01-16-12-36-00-00 taroballs@taroballs-PC:~$ cd /media/taroballs/taroballs/ taroballs@taroballs-PC: /media/taroballs/taroballs $

可以看到,我们的目录/media/taroballs/taroballs
挂载到/dev/sdb1 这个文件系统中.

umount我们的挂载盘比如:

?
1 2 taroballs@taroballs-PC:~$ df -lh | grep /dev/sdb1 /dev/sdb1       6.8G  4.1G  2.8G   60% /media/taroballs/taroballs

umount这个目录

?
1 2 3 4 taroballs@taroballs-PC:~$ umount /media/taroballs/taroballs taroballs@taroballs-PC:~$ df -lh | grep /dev/sdb1 taroballs@taroballs-PC:~$ #记得删除一定要后umount哦,不然二次写入谁也帮不了你呢。

通过inode节点恢复

?
1 2 3 taroballs@taroballs-PC:~$ mkdir recovertest taroballs@taroballs-PC:~$ cd recovertest/ taroballs@taroballs-PC:~ /recovertest $

执行恢复extundelete /dev/sdb1 --inode 2

?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 taroballs@taroballs-PC: /media/taroballs/taroballs $ sudo extundelete /dev/sdb1 --inode 2 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Group: 0 Contents of inode 2:   . .省略N行   File name                                       | Inode number | Deleted status .                                                 2 ..                                                2 deletetest                                        12             Deleted tmppasswd                                            14             Deleted

通过扫描发现了我们删除的文件夹,现在执行恢复操作。
(1)恢复单一文件tmppasswd

?
1 2 3 4 5 taroballs@taroballs-PC:~ /recovertest $  extundelete /dev/sdb1 --restore- file passwd   NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 46 descriptors loaded. Successfully restored file tmppasswd

恢复文件是放到了当前目录RECOVERED_FILES。
查看恢复的文件:

?
1 2 taroballs@taroballs-PC:~ /recovertest $ cat tmppasswd tcpdump:x:172:72::/: /sbin/nologin

(2)恢复目录deletetest

?
1 2 3 4 5 6 7 extundelete /dev/sdb1 --restore-directory  deletetest NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 46 descriptors loaded. Searching for recoverable inodes in directory deletetest ... 5 recoverable inodes found. Looking through the directory structure for deleted files ...

(3)恢复所有

?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 taroballs@taroballs-PC:~ /recovertest $ extundelete /dev/sdb1 --restore-all NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 46 descriptors loaded. Searching for recoverable inodes in directory / ... 5 recoverable inodes found. Looking through the directory structure for deleted files ... 0 recoverable inodes still lost. taroballs@taroballs-PC:~ /recovertest $ tree backuptest/ ├── deletetest │   └── innerfolder │       └── deletefile.txt └── tmppasswd   2 directories, 2 files

(4)恢复指定inode

?
1 2 3 4 5 6 7 taroballs@taroballs-PC:~ /recovertest $ extundelete /dev/sdb1 --restore-inode 14 NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 8 groups loaded. Loading journal descriptors ... 46 descriptors loaded. taroballs@taroballs-PC:~ /recovertest $ cat file .14 tcpdump:x:172:72::/: /sbin/nologin #注意恢复inode的时候,恢复 出来的文件名和之前不一样,需要单独进行改名。

最后附上extundelete的用法:

?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 $ extundelete --help Usage: extundelete [options] [--] device- file Options:    --version, -[vV]       Print version and exit successfully.    --help,                Print this help and exit successfully.    --superblock           Print contents of superblock in addition to the rest.                           If no action is specified then this option is implied.    --journal              Show content of journal.    --after dtime          Only process entries deleted on or after 'dtime' .    --before dtime         Only process entries deleted before 'dtime' . Actions:    --inode ino            Show info on inode 'ino' .    --block blk            Show info on block 'blk' .    --restore-inode ino[,ino,...]                           Restore the file (s) with known inode number 'ino' .                           The restored files are created in . /RECOVERED_FILES                           with their inode number as extension (ie, file .12345).    --restore- file 'path'  Will restore file 'path' . 'path' is relative to root                           of the partition and does not start with a '/'                           The restored file is created in the current                           directory as 'RECOVERED_FILES/path' .    --restore-files 'path' Will restore files which are listed in the file 'path' .                           Each filename should be in the same format as an option                           to --restore- file , and there should be one per line.    --restore-directory 'path'                           Will restore directory 'path' . 'path' is relative to the                           root directory of the file system.  The restored                           directory is created in the output directory as 'path' .    --restore-all          Attempts to restore everything.    -j journal             Reads an external journal from the named file .    -b blocknumber         Uses the backup superblock at blocknumber when opening                           the file system.    -B blocksize           Uses blocksize as the block size when opening the file                           system.  The number should be the number of bytes.    --log 0                Make the program silent.    --log filename         Logs all messages to filename. --log D1=0,D2=filename   Custom control of log messages with comma-separated     Examples below:       list of options.  Dn must be one of info, warn, or     --log info,error      error.  Omission of the '=name' results in messages     --log warn=0          with the specified level to be logged to the console.     --log error=filename  If the parameter is '=0' , logging for the specified                           level will be turned off.  If the parameter is                           '=filename' , messages with that level will be written                           to filename.     -o directory          Save the recovered files to the named directory.                           The restored files are created in a directory                           named 'RECOVERED_FILES/' by default.

到此这篇关于Linux下rm误删除文件的三种恢复方法的文章就介绍到这了,更多相关Linux rm删除文件恢复内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!

原文链接:https://www.cnblogs.com/cs-markdown10086/archive/2022/11/30/16938664.html

可以去百度分享获取分享代码输入这里。
声明

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

【腾讯云】云服务器产品特惠热卖中
搜索
标签列表
    关注我们

    了解等多精彩内容