Ext3 file system anti-deletion tool ext3grep Application Practice

Ext3 file system anti-deletion tool ext3grep Application Practice

I. Confusion caused by "rm-rf"

A well-known foreign Linux System Administrator Code contains such a "Use the rm-rf command with caution, unless you know what the command will do, the importance of this command to the system administrator. In actual work, the case of accidental data deletion caused by this command is not uncommon. Many system administrators have encountered or made such errors. Because developers are not familiar with the command, or are careless and neglected to manage it, the data is cleared in an instant after the command is executed. Linux does not have functions similar to the recycle bin, which means data loss. Although Linux provides a data recovery mechanism, this function is basically useless. To restore data, it cannot be completed through conventional means. At this time, you only need to find a professional data recovery company to restore data, this will undoubtedly cause a great deal of cost and cost, resulting in incalculable losses.

As a system administrator, you must be aware of data security and data protection, strictly abide by the relevant maintenance rules, and minimize the losses caused by such mistakes. Fortunately, in Linux, an open-source software is provided to restore accidentally deleted data. The ext3 file system data recovery tool ext3grep can be used to restore accidentally deleted data.

Ii. Installation and Use of ext3grep

 

Ext3grep is an open-source ext3 file system anti-deletion tool. Before ext3grep appears, it is basically impossible to restore data by conventional means after the data is deleted, although the debugfs command can restore the ext2 file system, the ext3 file system is powerless. Ext3 is a log-type file system. ext3grep analyzes the log information of the ext3 file system to restore deleted files and data.

 

Operating System Environment: CentOS release 6.4.

Ext3grep version: ext3grep-0.10.1.

Ext3grep Official Website: http://code.google.com/p/ext3grep/, you can download the latest ext3grep.pdf from here. The download is ext3grep-0.10.1.tar.gz.

 

Required System packages:
 

[root@localhost ~]# rpm -qa |grep e2fsprogse2fsprogs-1.41.12-21.el6.x86_64e2fsprogs-libs-1.41.12-21.el6.x86_64e2fsprogs-devel-1.41.12-21.el6.x86_64

The system must install the e2fsprogs-libs, otherwise there will be problems with the installation of ext3grep.

The compilation and installation process is as follows:

[root@localhost /opt]# tar zxvf ext3grep-0.10.1.tar.gz[root@localhost ext3grep-0.10.1]# ./configure[root@localhost ext3grep-0.10.1]# make[root@localhost ext3grep-0.10.1]# make install[root@localhost ext3grep-0.10.1]# ext3grep  -vRunning ext3grep version 0.10.1

In this way, the ext3grep installation is complete. The default ext3grep command is placed in the/usr/local/bin directory. The use of ext3grep is very simple. We will not introduce it here. You can use "ext3grep -- help" to obtain detailed help.

3. Restore accidentally deleted files and directories through ext3grep

 

1. Data recovery principles

When data in a partition is deleted by mistake, the first thing to do is to immediately unmount the partition where the deleted file is located, or re-mount the partition in read-only mode.

The reason for doing this is actually very simple: delete a file, that is, clear the sector pointer in the file inode node, and release the data block corresponding to the data, the actual files are still stored in the disk partition, but these deleted files may not always remain in the disk. When these released data blocks are re-allocated by the operating system, the deleted data will be overwritten. Therefore, immediately detaching the partition where the file is located can reduce the risk of Overwriting data in the data block, this increases the chances of data recovery.

 

2. ext3grep file recovery

 

(1) simulate an environment where data is accidentally deleted

The following describes how to use ext3grep to restore a data file in a simulated environment.

[Root @ localhost/] # mkdir/disk # create a mount point [root @ localhost/] # cd/mydata [root @ localhost mydata] # dd if =/dev/zero =/mydata/disk1 count = 102400 # simulate disk shard # zone, create an empty device 102400 + 0 records in102400 + 0 records out52428800 bytes (52 MB) copied, 1.20597 seconds, 43.5 MB/s [root @ localhost mydata] # mkfs. ext3/mydata/disk1 # format an empty device to ext3 [root @ localhost mydata] # mount-o loop/mydata/disk1/disk # mount the device to the/disk directory [root @ localhost mydata] # cd/disk/[root @ localhost disk] # cp/etc/profile/disk # copy a file to a simulated disk partition [root @ localhost disk] # cp/boot /initrd-2.6.18-164.11.1.el5xen.img/disk [root @ localhost disk] # echo "ext3grep test"> ext3grep.txt [root @ localhost disk] # mkdir/disk/ext3grep [root @ localhost disk] # cp/etc /hosts/disk/ext3grep [root @ localhost disk] # pwd/disk [root @ localhost disk] # ls-al total 2512drwxr-xr-x 4 root 4096 04-07. drwxr-xr-x 31 root 4096 04-07 16:45 .. drwxr-xr-x 2 root 4096 04-07 ext3grep-rw-r -- r -- 1 root 14 04-07 ext3grep.txt-rw ------- 1 root 2535991 04-07 initrd-2.6.18-164.11.1.el5xen.imgdrwx ------ 2 root 4096 04-07 lost + found-rw-r -- 1 root 1029 04-07 profile [root @ localhost disk] # md5sum profile # Get the file Verification Code a6e82d979bb95919082d9aceddf56c39 profile [root @ localhost disk] # md5sum initrd-2.6.18-164.11.1.el5xen.img limit initrd-2.6.18-164.11.1.el5xen.img [root @ localhost disk] # md5sum ext3grep.txt limit ext3grep.txt [root @ localhost disk] # rm-rf/disk/* # simulate accidental deletion data operation [root @ localhost disk] # ls (2 ). run the following command to detach a disk partition: [root @ localhost disk] # cd/opt # Switch to the/opt directory [root @ localhost/opt] # umount/disk # detach a simulated disk partition (3 ). run the following command to query the data recovery information: [root @ localhost/opt] # ext3grep/mydata/disk1 -- ls -- inode 2

After executing this command, ext3grep starts to search for information about recoverable data files, as shown in the output.

"Ext3grep/mydata/disk1 -- ls -- inode 2" is used to scan information about all files in the current file system, including existing and deleted files, the deleted file contains the D identifier. If you do not remember the name of the deleted file, you can use this method to obtain the name of the file to be restored.

You can obtain the path information of the file to be restored in the following way.

[root@localhost /opt]# ext3grep  /mydata/disk1  --dump-namesRunning ext3grep version 0.10.1Number of groups: 7Minimum / maximum journal block: 447 / 4561Loading journal descriptors... sorting... doneThe oldest inode block that is still in the journal, appears to be from 1270629014 = Wed Apr  7 16:30:14 2010Number of descriptors in journal: 63; min / max sequence numbers: 2 / 10Loading disk1.ext3grep.stage2... doneext3grepext3grep.txtext3grep/hostsinitrd-2.6.18-164.11.1.el5xen.imglost+foundprofile

To restore a deleted file, follow these steps. (4) restore a single file

[root@localhost /opt]# ext3grep  /mydata/disk1  --restore-file  ext3grep.txtRunning ext3grep version 0.10.1Number of groups: 7Minimum / maximum journal block: 447 / 4561Loading journal descriptors... sorting... doneThe oldest inode block that is still in the journal, appears to be from 1270629014 = Wed Apr  7 16:30:14 2010Number of descriptors in journal: 63; min / max sequence numbers: 2 / 10Writing output to directory RESTORED_FILES/Loading disk1.ext3grep.stage2... doneRestoring ext3grep.txt

The following operations are performed to restore a file in a specified directory: ext3grep.txt, the deleted file, is successfully restored by the output of the deleted file. So where is the recovered data stored? In this operation, execute the ext3grep command in the/opt directory, and store the recovered data files in the/opt/RESTORED_FILES directory, that is to say, ext3grep will automatically create a RESTORED_FILES directory under the current directory where the recovery command is executed. This directory is used to store recovered data.

[root@localhost /opt]# ext3grep  /mydata/disk1  --restore-file  ext3grep/hostsRunning ext3grep version 0.10.1Number of groups: 7Minimum / maximum journal block: 447 / 4561Loading journal descriptors... sorting... doneThe oldest inode block that is still in the journal, appears to be from 1270629014 = Wed Apr  7 16:30:14 2010Number of descriptors in journal: 63; min / max sequence numbers: 2 / 10Loading disk1.ext3grep.stage2... doneRestoring ext3grep/hosts

With the "-- restore-inode" parameter, you only need to specify the inode value corresponding to the file to restore the file. The operation is as follows, where the inode value is 12 and the profile file: note that, "-- restore-file" is followed by the recovery file path, which should be the relative path of the file. The relative path here refers to the path of the relative specified device, for example, the mount point of the device/mydata/disk1 is/disk, and the ext3grep.txt file is in the/disk directory, so you can directly specify the file name. If you want to restore the/disk/ext3grep/hosts file, the specified parameter should be "ext3grep/hosts", that is, the format specified in the Code above.
 

[root@localhost RESTORED_FILES]# ext3grep  /mydata/disk1   --restore-inode 12Running ext3grep version 0.10.1Number of groups: 7Minimum / maximum journal block: 447 / 4561Loading journal descriptors... sorting... doneThe oldest inode block that is still in the journal, appears to be from 1270629014 = Wed Apr  7 16:30:14 2010Number of descriptors in journal: 63; min / max sequence numbers: 2 / 10Writing output to directory RESTORED_FILES/Restoring inode.12

The following shows how to enter the RESTORED_FILES directory and verify whether the file is successfully restored:
 

[root@localhost /opt]# cd RESTORED_FILES[root@localhost RESTORED_FILES]# lsext3grep  ext3grep.txt  inode.12[root@localhost RESTORED_FILES]# md5sum ext3grep.txt 5afe55495cdb666daad667e1cd797dcb  ext3grep.txt[root@localhost RESTORED_FILES]# md5sum inode.12a6e82d979bb95919082d9aceddf56c39  inode.12

According to the verification results, this verification code is exactly the same as the verification code before the file is deleted. Therefore, the files recovered in this way are complete.

 

(5) Restore all deleted data

When there are few files to be restored, it is feasible to restore them one by one using the specified files described earlier. However, if you want to restore more than 1000 files, the efficiency is very low when you specify one by one. You need to use the "-- restore-all" parameter of the ext3grep command. The specific operation is as follows:

[Root @ localhost/opt] # ext3grep/mydata/disk1 -- restore-all Running ext3grep version 0.10.1Number of groups: 7 Minimum/maximum journal block: 447/4561 Loading journal descriptors... sorting... doneThe oldest inode block that is still in the journal, appears to be from 1270629014 = Wed Apr 7 16:30:14 2010 Number of descriptors in journal: 63; min/max sequence numbers: 2/10 Loading disk1.exgret3p. stage2... doneRestoring ext3grep.txt Restoring ext3grep/hostsRestoring initrd-2.6.18-164.11.1.el5xen.imgRestoring profile [root @ localhost/opt] # cd RESTORED_FILES/[root @ localhost RESTORED_FILES] # ls-al total limit 4 root 4096 04-07. drwxr-xr-x 31 root 4096 04-07 16:45 .. drwxr-xr-x 2 root 4096 04-07 ext3grep-rw-r -- r -- 1 root 14 04-07 ext3grep.txt-rw ------- 1 root 2535991 04-07 initrd-2.6.18-164.11.1.el5xen.imgdrwx ------ 2 root 4096 04-07 lost + found-rw-r -- 1 root 1029 04-07 profile

According to this output, the "-- restore-all" parameter restores all files that can be recovered from the specified storage device and stores them in the RESTORED_FILES directory. The "-- restore-all" parameter is very useful for restoring a large number of data files.