-bash-2.05b# dumpe2fs -h /dev/ubd/0
dumpe2fs 1.35 (28-Feb-2004)
Filesystem volume name:
Last mounted on:
Filesystem UUID: 47ce1382-4487-40db-949a-ce0b22d70cd0
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 384768
Block count: 768256
Reserved block count: 38412
Free blocks: 226824
Free inodes: 248837
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16032
Inode blocks per group: 501
Filesystem created: Tue Jul 27 12:59:32 2004
Last mount time: Sun Dec 27 18:55:42 2009
Last write time: Sun Dec 27 18:55:42 2009
Mount count: 5
Maximum mount count: 20
Last checked: Sat Feb 12 17:56:04 2005
Check interval: 15552000 (6 months)
Next check after: Thu Aug 11 18:56:04 2005
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 20cb2afa-b1ca-4f4d-974f-e54d63b4e3ff
Journal backup: inode blocks
The basic recovery process
In this section we will go step-by-step through the data recovery process and describe the tools, and their options, in detail. We start by listing a directory below.
[abe@abe-laptop test]$ ls -al
total 27
drwxrwxr-x 2 abe abe 4096 2008-03-29 17:48 .
drwx------ 71 abe abe 4096 2008-03-29 17:47 ..
-rwxr--r-- 1 abe abe 42736 2008-03-29 17:47 weimaraner1.jpg
In the listing above we can see that there is a file named weimaraner1.jpg in the test directory. This is a picture of my dog. I don't want to delete it. I like my dog.
[abe@abe-laptop test]$ rm -f *
Here we can see I am deleting it. Whoops! Sorry buddy. Let's gather some basic information about the system so we can begin the recovery process.
[abe@abe-laptop test]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 71G 14G 53G 21% /
/dev/sda1 99M 19M 76M 20% /boot
tmpfs 1007M 12K 1007M 1% /dev/shm
/dev/sdb1 887M 152M 735M 18% /media/PUBLIC
Here we see that the full path to the test directory (which is /home/abe/test) is part of the / filesystem, represented by the device file /dev/sda2.
[abe@abe-laptop test]$ su -
Password:
[root@abe-laptop ~]# debugfs /dev/sda2
Using su to gain root access, we can start the debugfs program giving it the target of /dev/sda2. The debugfs program is an interactive file system debugger that is installed by default with most common Linux distributions. This program is used to manually examine and change the state of a filesystem. In our situation, we're going to use this program to determine the inode which stored information about the deleted file and to what block group the deleted file belonged.
debugfs 1.40.4 (31-Dec-2007)
debugfs: cd /home/abe/test
debugfs: ls -d
1835327 (12) . 65538 (4084) .. <1835328> (4072) weimaraner1.jpg
After debugfs starts, we cd into /home/abe/test and run the ls -d command. This command shows us all deleted entries in the current directory. The output shows us that we have one deleted entry and that its inode number is 1835328 -- that is, the number between the angular brackets.
debugfs: imap <1835328>
Inode 1835328 is part of block group 56
located at block 1835019, offset 0x0f80
The next command we want to run is imap, giving it the inode number above so we can determine to which block group the file belonged. We see by the output that it belonged to block group 56.
debugfs: stats
[...lots of output...]
Blocks per group: 32768
[...lots of output...]
debugfs: q
Running the stats command will generate a lot of output. The only data we are interested in from this list, however, is the number of blocks per group. In this case, and most cases, it’s 32768. Now we have enough data to be able to determine the specific set of blocks in which the data resided. We're done with debugfs now, so we type q to quit.
refer:
http://www.securityfocus.com/infocus/1902
debugfs: dump <2048262> /home/jake/recovery.file
Especially if you can't unmount the file system containing the deleted data, debugfs is a less comfortable, but usable alternative if it is already installed on your system. (If you have to install it, you can use the more comfortable e2undel as well.) Just try a
/sbin/debugfs device
Replace device by your file system, e.g. /dev/hda1 for the first partition on your first IDE drive. At the "debugfs:" prompt, enter the command
lsdel
After some time, you will be presented a list of deleted files. You must identify the file you want to recover by its owner (2nd column), size (4th column), and deletion date. When found, you can write the data of the file via
dump
The inode_number is printed in the 1st column of the "lsdel" command. The file filename should reside on a different file system than the one you opened with debugfs. This might be another partition, a RAM disk or even a floppy disk.
Repeat the "dump" command for all files that you want to recover; then quit debugfs by entering "q".
refer:http://e2undel.sourceforge.net/recovery-howto.html
Disable ext3 boot-time check with tune2fs
by Ryan
on October 26, 2008
The ext3 file system forces an fsck once it has been mounted a certain number of times. By default this maximum mount count is usually set between 20-30. On many systems such as laptops which can be rebooted quite often this can quickly become a problem. To turn off this checking you can use the tune2fs command.
The tune2fs command utility operates exclusively on ext2/ext3 file systems.
To run these commands you must run the command as root or use sudo. You must also make sure that your filesystem is unmounted before making any changes. If you are doing this on your root partition the best solution is to use a LiveCD.
You can run tune2fs on the ext3 partition with the ‘-l‘ option to view what your current and maximum mount count is set to currently.
tune2fs -l /dev/sda1
...
Mount count: 2
Maximum mount count: 25
...
To turn off this check set the maximum count to 0 with the ‘-c‘ option.
# tune2fs -c 0 /dev/sda1
If you do not want to completely disable the file system checking, you can also increase the maximum count.
# tune2fs -c 100 /dev/sda1
-------
debugfs: params
Open mode: read-only
Filesystem in use: /dev/ubd/0
No comments:
Post a Comment