Linux Tutorial: Use the lsof command to restore deleted files

Linux Tutorial: Use the lsof command to restore deleted files

Deleting a file is actually just releasing the index points (information nodes) pointing to the data block. As long as it is not overwritten, the data is actually still on the hard disk. The key is to find the index point, and then grab the data in the data block it points to. Save it to another partition. After deleting a file by mistake with rm, the first thing we have to do is to ensure that no more data will be written to the partition where the file was deleted by mistake.

Restoring with the lsof command

The lsof command is used to view the files opened by your process, the process of opening the file, and the port (TCP, UDP) opened by the process. Retrieve/recover deleted files. It is a very convenient system monitoring tool, because the lsof command needs to access the core memory and various files, so it needs to be executed by the root user.

In the Linux environment, everything exists in the form of files, through which not only regular data can be accessed, but network connections and hardware can also be accessed. Therefore, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) sockets, etc., the system allocates a file descriptor for the application in the background, regardless of the nature of the file, the file descriptor is the application Interaction with the underlying operating system provides a common interface. Because the descriptor list of the file opened by the application provides a lot of information about the application itself, it will be very helpful for system monitoring and troubleshooting to be able to view this list through the lsof tool.

1. Grammar

lsof(选项)

2. Parameters

-a：列出打开文件存在的进程； 
-c<进程名>：列出指定进程所打开的文件； 
-g：列出GID号进程详情； 
-d<文件号>：列出占用该文件号的进程； 
+d<目录>：列出目录下被打开的文件； 
+D<目录>：递归列出目录下被打开的文件； 
-n<目录>：列出使用NFS的文件； 
-i<条件>：列出符合条件的进程。（4、6、协议、:端口、 @ip ） 
-p<进程号>：列出指定进程号所打开的文件； 
-u：列出UID号进程详情； 
-h：显示帮助信息； 
-v：显示版本信息。

3. use

Check

lsof -i: (port) Check which processes are accessing this port, such as port 22

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)

The meaning of each column information output by lsof is as follows:

• COMMAND: the name of the process
• PID: process identifier
• USER: process owner
• FD: file descriptor, the application identifies the file through the file descriptor. Such as cwd, txt, etc.
• TYPE: file type, such as DIR, REG, etc.
• DEVICE: Specifies the name of the disk
• SIZE: the size of the file
• NODE: index node (identification of the file on disk)
• NAME: the exact name of the opened file

recover files

Some system logs can be restored using lsof, provided that the process must exist. Here we take the most commonly used /var/log/messages as an example. You'd better make a backup before doing the test.

#备份
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

The process is running, and then I will delete the file /var/log/messages

shell> rm /var/log/messages

After deleting, I will look at the changes in this process

shell> lsof |grep /var/log/messages
rsyslogd   1737      root    1w      REG                8,2   5716123     652638 /var/log/messages (deleted)

You can see that there has been a change. After comparing the two, I found that there are many (deleted). To find where this file is also look at this

PID: 1737 FD: 1 Then we have directly entered /proc/1737/FD/1 and checked it with 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

I saw that 1 corresponds to /var/log/messages (deleted), to see if the file is the one we want:

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 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

Compare backup files:

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 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Fri Nov 22 03:15:09 UTC 2013

Compare and find that the data is the same, restore

shell> cat 1 > /var/log/messages

Again, the premise of recovery is that the process must exist.