Linux uses lsof to recover deleted files

Prerequisite: The file is still accessed by the process after it has been deleted, so it is more appropriate for the file to be used to recover the log class.

When a Linux computer is compromised, it is common for a log file to be deleted to mask the attacker's whereabouts. Administrative errors can also cause accidental deletion of important files, such as accidental deletion of the active transaction log of the database when the old log is cleaned up. Sometimes these files can be recovered by lsof.

When a process opens a file, it still exists on disk as long as the process remains open for that file, even if it is deleted. This means that the process does not know that the file has been deleted, and it can still read and write to the file descriptor that was provided to it when the file was opened. In addition to the process, this file is not visible because its corresponding directory indexing node has been deleted.

In the/proc directory, it contains various files that reflect the kernel and the process tree. The/proc directory mounts an area that is mapped in memory, so these files and directories do not exist on disk, so when we read and write to these files, we actually get the relevant information from memory. Most lsof-related information is stored in the directory named by the process's PID, that is, the/proc/1234 contains information about the process with PID 1234. There are various files in each process directory that allow the application to simply understand the memory space of the process, file description characters, symbolic links to files on disk, and other system information. The LSOF program uses this information and other information about the internal state of the kernel to produce its output. So lsof can display information such as the file descriptor of the process and the associated file name. That is, we can find information about the file by accessing the file descriptor of the process. When a file in the system is accidentally deleted, as long as there are processes in the system that are accessing the file, we can recover the contents of the file from the/proc directory by lsof.

If the/var/log/messages file is deleted because of a misoperation, then the method to restore the/var/log/messages file is as follows: First use lsof to see if there is currently a process open/var/logmessages file, as follows:

# lsof |grep/var/log/messages
command    PID user   fd   TYPE DEVICE SIZE/OFF     NODE NAME
syslogd   14572      root    1w       reg      253,0     5584     1737237/var/log/messages
#rm –f/var/log/messages
# lsof |grep/var/log/messages
command     PID user   fd   TYPE DEVICE size/off    NODE NAME
syslogd   14572      root    1w      REG       253,0     5584    1737237/var/log/messages (deleted)
 
From the above information you can see that the PID 14572 (syslogd) Open file has a file descriptor of 1. You can also see that/var/log/messages has been marked for deletion. Therefore, we can view the corresponding information in/PROC/14572/FD/1 (each of the digitally named files that represent the process) in the case of FD, as follows:

# tail-n 10/PROC/14572/FD/1
Feb 4 20:02:25 host191 kernel:klogd 1.4.1, log Source =/proc/kmsg started.
Feb 4 20:02:45 host191 root:aaa
Feb 4 20:05:07 host191 dhclient:dhcprequest on eth0 to 192.168.0.254 Port 67
Feb 4 20:05:07 host191 dhclient:dhcpack from 192.168.0.254
Feb 4 20:05:07 host191 dhclient:bound to 192.168.0.191-renewal in 718.
Feb 4 20:15:50 host191 syslogd 1.4.1:restart.
Feb 4 20:15:50 host191 kernel:klogd 1.4.1, log Source =/proc/kmsg started.
Feb 4 20:17:05 host191 dhclient:dhcprequest on eth0 to 192.168.0.254 Port 67
Feb 4 20:17:05 host191 dhclient:dhcpack from 192.168.0.254
Feb 4 20:17:05 host191 dhclient:bound to 192.168.0.191-renewal in 804 seconds.# CAT/PROC/14572/FD/1 >/var/log/me Ssages

The following describes the files that were mistakenly deleted using lsof on the Fedora Core 5 system:

Environment
Host: Using micro-MU independent host, a virtual stand-alone host based on VMware.
System: Fedora Core 5
Kernel: 2.6.16-1.2122_FC5
Lsof version:

[Zhaoke@fedora5 ~]$/usr/sbin/lsof-v
Lsof Version Information:
revision:4.77

Preparatory work:
If your system does not have lsof installed, it can be obtained from the author's website or Pbone.
Author Website: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
pbone:http://rpm.pbone.net/

Recovery process:
First, we need to create a text file, delete and then restore:

[Zhaoke@fedora5 ~]$ man lsof | Col-b > MyFile

Then look at the contents of the file:

[Zhaoke@fedora5 ~]$ Less myfile

You can see lsof all the text help information.

Now press Ctrl-z to exit the less command, and then view the file property information at the shell prompt:

[Zhaoke@fedora5 ~]$ Stat myfile
File: ' MyFile '
size:116549 blocks:240 IO block:4096 Regular file
device:fd00h/64768d inode:492686 links:1
Access: (0664/-rw-rw-r–) Uid: (505/zhaoke) Gid: (505/zhaoke)
access:2006-11-20 12:59:38.000000000 +0800
modify:2006-11-20 12:59:34.000000000 +0800
change:2006-11-20 12:59:34.000000000 +0800

No problem, continue with the following work:

[Zhaoke@fedora5 ~]$ RM myfile
[Zhaoke@fedora5 ~]$ Ls-l myfile
Ls:myfile:No such file or directory
[Zhaoke@fedora5 ~]$ Stat myfile
Stat:cannot stat ' myfile ': No such file or directory

The MyFile file was deleted.

At this point, you do not terminate the process that is still using the file. Because once terminated, the file will be difficult to recover.

Now we start to retrieve the data, first use lsof to see:

[Zhaoke@fedora5 ~]$ lsof | grep myfile

Less 9104 zhaoke 4r REG 253,0 116549 492686/home/zhaoke/myfile (Deleted)

The first vertical line is the name of the process (the command name), the second vertical line is the process number (PID), the fourth vertical line is the file descriptor (r means normal file), and now you know that the 9104 process still has open files and the file descriptor is 4. So we start copying data from/Proc. You may consider using CP-A, but in effect, you will copy a symbolic link to the deleted file:

[Zhaoke@fedora5 ~]$ ls-l/PROC/9104/FD/4
Lr-x--1 zhaoke zhaoke Nov 13:00/proc/9104/fd/4->/home/zhaoke/myfile (Deleted)
[Zhaoke@fedora5 ~]$ cp-a/PROC/9104/FD/4 Myfile.wrong
[Zhaoke@fedora5 ~]$ ls-l Myfile.wrong
lrwxrwxrwx 1 zhaoke zhaoke Nov 13:02 myfile.wrong->/home/zhaoke/myfile (Deleted)
[Zhaoke@fedora5 ~]$ file Myfile.wrong
Myfile.wrong:broken symbolic link to '/home/zhaoke/myfile (deleted) '
[Zhaoke@fedora5 ~]$ FILE/PROC/9104/FD/4
/PROC/9104/FD/4: Broken symbolic link to '/home/zhaoke/myfile (deleted) '

Then, copy the data using the CP:

[Zhaoke@fedora5 ~]$ CP/PROC/9104/FD/4 myfile.saved

Finally, confirm the file:

[Zhaoke@fedora5 ~]$ ls-l myfile.saved
-rw-rw-r–1 zhaoke Nov zhaoke 116549 13:03 myfile.saved
[Zhaoke@fedora5 ~]$ man lsof | Col-b > Myfile.new
[Zhaoke@fedora5 ~]$ CMP myfile.saved myfile.new

CMP comparison shows no indication that two files are identical and the recovery is successful.

Commonly used parameter lists:

lsof filename Displays all processes that open the specified file

Lsof-a indicates that the results are displayed when all two parameters must be met

Lsof-c string Displays all open files for the process containing the specified characters in the command column

Lsof-u username display files that are open by the owning user process

Lsof-g GID shows the process status of the attribution GID

Lsof +d/dir/displays files that are opened by the process in the directory

Lsof +d/dir/Ibid, but will search all directories under the directory, the time is relatively long

Lsof-d FD Displays the process of specifying a file descriptor

Lsof-n does not convert IP to hostname, the default is not to add-n parameter

Lsof-i is used to show the conditions of a qualifying process

At this point, the file is restored. However, remember to restart the application, otherwise, the newly generated log may not be able to write the newly generated file Oh ~ ~