Linux restores the deleted file method

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 remains on disk as long as the process persists and the file is opened, 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 due to 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:

The code is as follows	Copy Code
[Root@station90 yum.repos.d]# lsof | Grep/var/log/messages SYSLOGD 2699 Root 1w REG 8,2 480817 330592/var/log/messages (Deleted)

From the above information you can see that the PID 2699 (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 the/PROC/2699/FD/1 (each of the digitally named files in the FD file descriptor), as follows:

code is as follows

copy code

[Root@station90 fd]# pwd /proc/2699/fd [root@station90 fd]# Cat 1 | head-n 5 out of 08:59:02 station90 syslogd 1.4.1:restar T. 10:44:22 station90 syslogd 1.4.1:restart. 10:44:22 station90 kernel:klogd 1.4.1, log Source =/proc/kmsg started. 10:44:22 station90 kernel:linux version 2.6.18-164.el5 (mockbuild@x86-003.build.bos.redhat.com) (GCC version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Aug 15:51:48 EDT 2009 10:44:22 station90 Kernel:command Line : Ro root=label=/rhgb quiet

As you can see from the above information, you can see the/PROC/2699/FD/1 to get the data you want to recover. If you can view the data by using a file descriptor, you can use I/O redirection to copy it to a file, such as:

The code is as follows	Copy Code
CAT/PROC/2699/FD/1 >/var/log/messages

Before the recovery, timely touch of the/var/log/messages file is also no problem

This method of recovering deleted files is useful for many applications, especially log files and databases.

Other methods Www.111cn.net

1, EXT2 file system structure of a simple introduction

In the Ext2 file system used by Linux, files are stored in blocks, and by default the size of each block is 1K, and different blocks are distinguished by block numbers. Each file also has a node that contains information such as file owners, read and write permissions, file types, and so on. For a file less than 12 blocks, the block number of the file data block is stored directly in the node. If the file is greater than 12 blocks, then the node stores a block number of an indirect block after 12 block numbers, in the block corresponding to this indirect block number, the block number of 256 file blocks is stored (each block number in the Ext2fs occupies 4 bytes, so that the block number that can be stored in a block is 1024/4=256). If there is a larger file, there will also be a level two indirect block and the * * Indirect block in the node.

2, restore the mistakenly deleted the document method

Most Linux distributions provide a DEBUGFS tool that you can use to edit the Ext2 file system. But before using this tool, there is still work to be done.

The partition in which the deleted file was mistakenly mounted is first reproduced in read-only mode. Use the following command: (assuming the file is in/usr partition)

Mount–r–n–o Remount/usr-r represents a read-only mount;-n means that the/etc/mtab is not written, and if the file on the/etc is restored, this argument is added. If the system says XXX partion busy, you can use the Fuser command to see which processes use the files on this partition:

The code is as follows	Copy Code
Fuser–v–m/usr

If there are no important processes, use the command to stop them:

The code is as follows	Copy Code
Fuser-k–v–m/usr

You can then mount the file systems again.

If you are installing all the files in one large/partition, you can use Linux single into Single-user mode at the boot prompt to minimize the chance that the system will write data to the hard disk, or simply hang the hard drive on another machine. In addition, the recovered data should not be written to/above to avoid damaging those useful data. If there are dos/windows on the machine, you can write to these partitions:

The code is as follows	Copy Code
Mount–r–n/dev/hda1/mnt/had

Then you can perform DEBUGFS: (assuming Linux is/dev/hda5)

The code is as follows	Copy Code
#debugfs/dev/hda5

The Debugfs prompt Debugfs will appear:

Use the Lsdel command to list information for a number of deleted files:

The code is as follows	Copy Code
Word-wrap:break-word "bgcolor= #f3f3f3 > Debugfs:lsdel debugfs:2692 deleted inodes found. Inode Owner Mode Size Blocks time deleted 164821 0 100600 8192 1/1 Sun May 13 19:22:46 2001 36137 0 100644 4 1/1 Tue APR 24 10:11:15 2001 196829 0 100644 149500 38/38 Mon May 27 13:52:04 2001

There are a lot of files listed (here are 2,692), the first field is the file node number, the second field is the file owner, the third field is read and write permissions, then the file size, the number of blocks, delete time.

Then you can judge the size of the file and the date of deletion to determine what we need. For example, we want to restore the node is 196829 files:

You can look at the file data status first:

code is as follows

copy code

Debugfs:stat <196829> inode:196829 type:regular mode:0644 flags:0x0 version:1 user:0 Group: 0 size:149500 File acl:0 Directory acl:0 links:0 blockcount:38 fragment:address:0 number:0 Size : 0 ctime:0x31a9a574-www.111cn.Net Mon could 13:52:04 2001 Atime:0x31a21dd1-Tue May 21 20:47:29 2001< br> Mtime:0x313bf4d7--Tue Mar 5 08:01:27 2001 dtime:0x31a9a574--Mon May-13:52:04 2001 Block S: 594810 594811 594814 594815 594816 594817 total:38

You can then recover the file with the dump command:

The code is as follows	Copy Code
Debugfs:dump <196829>/mnt/hda/01.sav

This will restore the file. Exit Debugfs:

The code is as follows	Copy Code
Debugfs:quit

Another way is to manually edit the Inode:

code is as follows	copy code
Debugfs:mi <196829> Mode [0100644] User ID [0] Group ID [0] Size [149500] Creation Tim 　　e [0x31a9a574] Modification time [0x31a9a574] Access time [0x31a21dd1] deletion time [0x31a9a574] 0 Link count [0] 1 block count [+] File flags [0x0] Reserved1 [0] File ACL [0] Directory AC l [0] Fragment address [0] Fragment number [0] Fragment size [0] Direct block #0 [594810] Tr Iple Indirect block [0]

Each time you use the MI instruction to display one line of information for editing, the other rows can be confirmed by return directly, the deletion times to 0 (not deleted), Link count to 1. After the change, exit Debugfs:

The code is as follows	Copy Code
Debugfs:quit

Then use fsck to check/dev/hda5

The code is as follows	Copy Code
Fsck/dev/hda5

The program says to find the missing block of data and put it in the lost+found. The files in this catalogue are what we want.