对于rm,很多人都有惨痛的教训。我也遇到一次，一下午写的程序就被rm掉了，幸好只是一个文件，第二天很快又重新写了一遍。但是很多人可能就不像我这么幸运了。本文收集了一些在Linux下恢复rm删除的文件的方法，给大家作为参考。
首先，最好的方法是避免这个问题，以下是几点建议:
1、rm -rf误操作的后果是可怕的，rm -f也要三思而行，不能轻易使用。
2、做好数据备份。
3、用一些策略避免出错:
提倡在shell下用 TAB 补全，用脚本执行任务，减少出错的机会。或者编写一个脚本，起名rm，在脚本里将真实的rm改为mv ，将删除的都mv到一个指定的目录里面，定期清理。
那么rm删除的文件还能恢复吗?
rm的man里面有如下说法:
请注意，如果使用 rm 来删除文件，通常仍可以将该文件恢复原状。如果想保证该文件的内容无法还原，请考虑使用 shred，Wipe，Secure-delete是一个安全文件删除工具的集合，其中包含srm (secure_deletion) 工具Linux 中永久安全地删除“文件和目录”的三种方法-linux永久删除文件夹
- yum install coreutils-8.22-24.el7_9.2.x86_64 -y
-
- yum install wipe
- yum install secure-delete
所以理论上rm删除的文件是还能恢复的。删掉文件其实只是将指向数据块的索引点(information nodes)释放，只要不被覆盖，数据其实还在硬盘上，关键在于找出索引点，然后将其所指数据块内的数据抓出，再保存到另外的分区。在用rm误删除文件后，我们要做的第一件事就是保证不再向误删文件的分区写数据。
lsof命令用于查看你进程开打的文件，打开文件的进程，进程打开的端口(TCP、UDP)。找回/恢复删除的文件。是十分方便的系统监视工具，因为lsof命令需要访问核心内存和各种文件，所以需要root用户执行。
在linux环境下，任何事物都以文件的形式存在，通过文件不仅仅可以访问常规数据，还可以访问网络连接和硬件。所以如传输控制协议 (TCP) 和用户数据报协议 (UDP) 套接字等，系统在后台都为该应用程序分配了一个文件描述符，无论这个文件的本质如何，该文件描述符为应用程序与基础操作系统之间的交互提供了通用接口。因为应用程序打开文件的描述符列表提供了大量关于这个应用程序本身的信息，因此通过lsof工具能够查看这个列表对系统监测以及排错将是很有帮助的。
1.语法
lsof(选项)
2.参数
- -a：列出打开文件存在的进程；
- -c<进程名>：列出指定进程所打开的文件；
- -g：列出GID号进程详情；
- -d<文件号>：列出占用该文件号的进程；
- +d<目录>：列出目录下被打开的文件；
- +D<目录>：递归列出目录下被打开的文件；
- -n<目录>：列出使用NFS的文件；
- -i<条件>：列出符合条件的进程。（4、6、协议、:端口、 @ip ）
- -p<进程号>：列出指定进程号所打开的文件；
- -u：列出UID号进程详情；
- -h：显示帮助信息；
- -v：显示版本信息。
3.使用
查看
lsof -i:（端口） 查看这个端口有那些进程在访问，比如22端口
- [root@k8s-worker27-65 fd]# lsof -i:22
- COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
- sshd 1045 root 3u IPv4 20767 0t0 TCP *:ssh (LISTEN)
- sshd 1045 root 4u IPv6 20769 0t0 TCP *:ssh (LISTEN)
- sshd 6971 root 3u IPv4 36849349 0t0 TCP k8s-worker27-65.local:ssh->192.168.0.254:messageservice (ESTABLISHED)
lsof输出各列信息的意义如下：
恢复文件
利用lsof可以恢复一些系统日志，前提是这个进程必须存在。这里就拿最常用的/var/log/messages来举例说明，大家在做测试的时候最好先备份一下。
- cp /var/log/message /var/log/message_bac
- sof |grep /var/log/message
- rsyslogd 1737 root 1w REG 8,2 5716123 652638 /var/log/messages
进程在运行中，接下来我就把/var/log/messages这个文件删掉
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 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），看看文件是不是我们要的文件:
- 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
对比备份文件：
- 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
对比发现数据是一样的，恢复
shell> cat 1 > /var/log/messages
再次提醒，恢复前提是这个进程必须存在。