Talking about the anti-deletion method of Linux file system

As a multi-user, multi-tasking operating system, files deleted under Linux are difficult to recover once they are deleted. Although the delete command simply deletes the mark in the file node and does not actually clear the file content, other users and some processes that have write actions will quickly overwrite the data. However, for the Linux used by the family, or if you remedy it after accidentally deleting the file, you can still recover it.

1. Brief introduction of Ext2 file system structure

In the Ext2 file system used by Linux, files are stored in blocks. By default, the size of each block is 1K. Different blocks are distinguished by block numbers. Each file also has a node, which contains information such as file owner, read and write permissions, and file type. For a file of less than 12 blocks, the block number of the file block is stored directly in the node. If the file is larger than 12 blocks, the node stores the block number of an indirect block after 12 block numbers. In the block corresponding to the indirect block number, the block number of 256 blocks of data blocks is stored (each block in Ext2fs) The number occupies 4 bytes, so the block number that can be stored in one block is 1024/4=256). If there is a larger file, then there will be a secondary indirect block and a tertiary indirect block in the node.

2. Recovering files that have been deleted by mistake

Most Linux distributions provide a debugfs tool that can be used to edit the Ext2 file system. However, there is still some work to be done before using this tool.

First remount the partition where the file was deleted by mistake. Use the following command: (assuming the file is in the /usr partition)

mount ?Cr ?Cn ?Co remount /usr

-r means read-only mode mount; -n means not write/Etc/mtab, if it is to restore the file on /etc, add this parameter. If the system says xxx partion busy, you can use the fuser command to see which processes are using this partition?n:

fuser ?Cv ?Cm /usr

If there are no important processes, Stop them with the following command:

fuser -k ?Cv ?Cm /usr

Then you can remount these filesystems.

If you install all the files in a large /partition, you can use linux single to enter the single-user mode at the boot prompt, to minimize the chance of the system process writing data to the hard disk, or Simply hang the hard drive on another machine. In addition, the recovered information should not be written/above to avoid destroying useful information. If you have dos/windows on your machine, you can write to these partitions:

mount ?Cr ?Cn /dev/hda1 /mnt/had

Then you can execute debugfs: (assuming Linux is /dev/hda5)

#debugfs /dev/hda5

The debugfs prompt debugfs will appear:

Use the lsdel command to list information about many deleted files. :

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

debugfs:
There are many files listed (Found 2692 here), the first field is the file node number, the second field is the file owner, the third field is the read and write permissions, then the file size, the number of blocks, the deletion timeThen you can judge which ones we need based on the file size and the date of deletion. For example, we want to restore the file whose node is 196829:

You can first check the status of the file:

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 < Br>

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x31a9a574 -- Mon May 27 13:52:04 2001

atime: 0x31a21dd1 -- Tue May 21 20:47:29 2001

mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 2001

dtime: 0x31a9a574 -- Mon May 27 13:52:04 2001

BLOCKS:

594810 594811 594814 594815 594816 594817

..................................

TOTAL: 38

Then you can use the dump command to restore the file:

debugfs:dump <196829> /mnt/hda/01.sav

This will restore the file. Exit debugfs:

debugfs:quit

Another way is to manually edit the inode:

debugfs:mi <196829>

Mode [0100644]

User ID [0]

Group ID [0]

Size [149500]

Creation time [0x31a9a574]

Modification Time [0x31a9a574]

Access time [0x31a21dd1] ​​

Deletion time [0x31a9a574] 0

Link count [0] 1

Block count [38]

File flags [0x0]

Reserved1 [0]

File acl [0]

Directory acl [0]

Fragment Address [0]

Fragment number [0]

Fragment size [0]

Direct Block #0 [594810]

............... ...................

Triple Indirect Block [0]

After using the mi command, one line of information is displayed for editing each time. Other lines can be confirmed by pressing Enter to confirm. Time changed to 0 (not deleted), Link count changed to 1After debugging, exit debugfs:

debugfs:quit

Then use fsck to check /dev/hda5

fsck /dev/hda5

The program will find The missing data block is placed in lost+found. The files in this directory are what we want.