Undeleting in Linux? Its possible, here's how...
Results 1 to 7 of 7

Thread: Undeleting in Linux? Its possible, here's how...

  1. #1
    Senior Member
    Join Date
    Sep 2001
    Posts
    121

    Exclamation Undeleting in Linux? Its possible, here's how...

    If there are any problems with my post please write me and tell me I would really appreciate it.

    http://www.linuxdoc.org/HOWTO/mini/E...ndeletion.html <-- Source of my information

    Alright I'll attempt to do justice to the HOWTO I just read. I should use the information and master the process before I make an attempt at discribing the process but I figure if this post interests you, you'll just visit the page and read it in-depth on your own.

    Recovering a file on a Linux (and I suppose Unix also) system is possible. The programs for Unix may be the same and/or the source will be usable for both platforms... anyways, the deletion of a file merely takes away the "labeling" of the file. The files you delete are still on the system but not recognized as information but now as usable space on the hard drive. Information on the system that stays "open" will be written over eventually so the speed at which recovery takes place is essential. Ways of "file protection" is covered in the HOWTO, very useful information, but I wont get into that. If your interested the reference is at the top of this post.

    I'm going to quickly discribe the process and undestanding of it but not with all details. Those who know the progams that are mentioned should be able to figure it out if they try.

    First off recovery rate is only about 80% and the % goes down with the amount of time between deletion and attempt of recovery. Also the amount of users on system and location of file are factors. If the file is located on a "busy" partition then it is urgent to recover immediately as the OS will assign the blocks if not found in time. There are 2 ways that you can undelete the file: One is removing the "flag" noting it as deleted on the inode itself. Second, safer and slower, work out where the data is and write it to a new file. The first step is unmounting partition that the data was stored on. If the partition is a vital part of the system like the root partition then its best to image the whole partition and mount using loopback... (you want to work on the partiton that the data is on... the image of the partition wont image deleted files unless you are making a exact copy and that would be slow and useless...) an example of the loopback is:

    "# cp /dev/hda5 /root/working
    # mount -t ext2 -o loop /root/working /mnt"

    He mentions a warrning about older versions of mount might not be capable of this but the HOWTO is also about 2 yrs old so I'm sure almost all can get this to work now. This will get your root partition innactive so that your actions wont screw up the system you are trying to fix. If problems do occur after finished you can always copy the image over the existing data and fix the problems you inflicted on the system... When saving the data put it on a seperate partition from the one you are working on. If you have no other partition he suggests this:

    "# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
    # mke2fs -v -m 0 /dev/ram0 2048
    # mount -t ext2 /dev/ram0 /mnt

    This creates a 2MB ramdisk volume, and mounts it on /mnt. "

    That will allow you hopefully enough space for the data you wish to recover... size can be changed if needed. Here is another warrning:

    "A short word of warning: if you use kerneld (or its replacement kmod in 2.2.x and later 2.1.x kernels) to automatically load and unload kernel modules, then don't unmount the ramdisk until you've copied any files from it onto non-volatile storage. Once you unmount it, kerneld assumes it can unload the module (after the usual waiting period), and once this happens, the memory gets re-used by other parts of the kernel, losing all the painstaking hours you just spent recovering your data. "

    For reading into the partition to find the information he recommends using the program fsgrab. (sounds like he programmed it, if you dont have you can use dd instead but he says his fsgrab is faster.) To download it you can get it at:
    http://pobox.com/~aaronc/tech/fsgrab-1.2.tar.gz

    Now it's time for detection of deleted files using debugfs. debugfs -w will allow the ability to directly change the inodes (the first way I mentioned to restore the files). When in debugfs use lsdel to see the files that are your possibilities. Here is a pipe so you can view the information in lsdel.out or any other file of choice:

    # echo lsdel | debugfs /dev/hda5 > lsdel.out

    Using the date, size, owners and information given you must decide what is your data. debugfs has a stat command that will give you more data about each inode that you need more information about. Here is an example of useage on inode 148003 "debugfs: stat <148003>"
    In the HOWTO it tells how to automate it to make it easier to view a lot of files stats if you have a lot of files to find. (If you are interested in that you will have to view the HOWTO)

    "If the file was no more than 12 blocks long, then the block numbers of all its data are stored in the inode: you can read them directly out of the stat output for the inode. Moreover, debugfs has a command which performs this task automatically. To take the example we had before, repeated here:

    debugfs: stat <148003>
    Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
    User: 503 Group: 100 Size: 6065
    File ACL: 0 Directory ACL: 0
    Links: 0 Blockcount: 12
    Fragment: Address: 0 Number: 0 Size: 0
    ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
    atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
    mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
    dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
    BLOCKS:
    594810 594811 594814 594815 594816 594817
    TOTAL: 6

    This file has six blocks. Since this is less than the limit of 12, we get debugfs to write the file into a new location, such as /mnt/recovered.000:

    debugfs: dump <148003> /mnt/recovered.000

    Of course, this can also be done with fsgrab; I'll present it here as an example of using it:

    # fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
    # fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000"

    This was an example of recovery of a file with less than 12 blocks but for longer files there is more that is required. (I'm sure you were expecting that) As you saw in the example it shows the BLOCKS in the inode from which the file you want is contained. The first 12 blocks are stored directly into the inode "direct blocks". IF the file is longer than the 12 it has an "indirect block", "doubly indirect block", and "triply indirect block" that will have 256 additonal blocks... indirect blocks have 256 additonal blocks, doubly indirect blocks have 256 additonal indirect blocks adn the triply indirect blocks have 256 additional doubly indirect blocks. That is very important to understand in the recovery process so you should know this.

    "Now, the kernel implementation for all versions up to and including 2.0.36 unfortunately zeroes all indirect blocks (and doubly indirect blocks, and so on) when deleting a file. So if your file was longer than 12 blocks, you have no guarantee of being able to find even the numbers of all the blocks you need, let alone their contents. The only method I have been able to find thus far is to assume that the file was not fragmented: if it was, then you're in trouble."

    *0-12 ---The block numbers are stored in the inode, as described above.

    *13-268 ---After the direct blocks, count one for the indirect block, and then there are 256 data blocks.

    *269-65804 ---As before, there are 12 direct blocks, a (useless) indirect block, and 256 blocks. These are followed by one (useless) doubly indirect block, and 256 repetitions of one (useless) indirect block and 256 data blocks.

    *65805-or more ---The layout of the first 65804 blocks is as above. Then follow one (useless) triply indirect block and 256 repetitions of a `doubly indirect sequence'. Each doubly indirect sequence consists of a (useless) doubly indirect block, followed by 256 repetitions of one (useless) indirect block and 256 data blocks.

    Even though these numbers coincide with where they may be placed there is no guarantee that the data will not have been displaced or overwritten. The longer the file the more chance for "flaws" in the reconstruction.

    "You should note that I assume throughout that your blocksize is 1024 bytes, as this is the standard value. If your blocks are bigger, some of the numbers above will change. Specifically: since each block number is 4 bytes long, blocksize/4 is the number of block numbers that can be stored in each indirect block. So every time the number 256 appears in the discussion above, replace it with blocksize/4. The `number of blocks required' boundaries will also have to be changed."

    recovering a longer file:

    BLOCKS:
    8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583
    TOTAL: 14

    recovering the first 12 blocks which are included in this inode:
    # fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001

    now 8326 is an indirect block which can be ignored but is followed by 256 so:
    # fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001

    "The final block listed in the inode is 8583. Note that we're still looking good in terms of the file being contiguous: the last data block we wrote out was number 8582, which is 8327 + 255. This block 8583 is a doubly indirect block, which we can ignore. It is followed by up to 256 repetitions of an indirect block (which is ignored) followed by 256 data blocks. So doing the arithmetic quickly, we issue the following commands. Notice that we skip the doubly indirect block 8583, and the indirect block 8584 immediately (we hope) following it, and start at block 8585 for data.

    # fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001
    # fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001
    # fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001
    # fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001
    # fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001
    # fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001

    Adding up, we see that so far we've written 12 + (7 * 256) blocks, which is 1804. The `stat' results for the inode gave us a `blockcount' of 3616; unfortunately these blocks are 512 bytes long (as a hangover from UNIX), so we really want 3616/2 = 1808 blocks of 1024 bytes. That means we need only four more blocks. The last data block written was number 10125. As we've been doing so far, we skip an indirect block (number 10126); we can then write those last four blocks.

    # fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001

    Now, with some luck the entire file has been recovered successfully."

    The modifing of the inodes directly (the first way) I will get into now... last. This will only work for files 12 blocks and smaller (that is what I have gathered from this anyways.) In the debugfs use the mi command on the inode you wish to examine and change. Set the usage count to 1 and the deletion time to 0. After you finish the debugfs exit out and run:

    # e2fsck -f /dev/hda5

    The files have been literally undeleted by reasigning them. e2fsck will just review the inodes to make the files "appear" when you mount the system the next time.

    Well this has taken me a good while to do and rewrote at least half of it... some of the information is directly quoted from the page I referenced to you. I included more information that I first thought so if you desire to review his page you will just get more clarity and some other pointers... IMPORTANT: on his page it will tell you how to remove the garbage at the end of the files you have just created using dd. That is all I have to say for now. Thank you for reading... I hope you learned as much as I did... lol use the -i when using rm

    I'm sorry if my wording confuses you I tried to review my work but I'm tired now, goodnight

    Tuskin

  2. #2
    Senior Member
    Join Date
    Aug 2001
    Posts
    100
    not bad...
    but i'd rather use this http://lde.sourceforge.net/
    LDE (linux disk editor). it's a free easy to use app to recover lost or deleted files...

    ------------------------------------------------------------------------------------------------------------------------
    "Knowledge is the Real Power"
    \"Knowledge is the Real Power\"

  3. #3
    Senior Member
    Join Date
    Sep 2001
    Posts
    121
    I wrote this because no one I talked to on here knew how to undelete stuff... I looked around a little and found the information you see here and put it up for others. The program you gave a link to looks like a more automated way to do it (easier). The control of how much data you actually examine would be my concern but I'll have to use it to actually determine its ability. Thanks for the link.

  4. #4
    Senior Member linuxcomando's Avatar
    Join Date
    Sep 2001
    Posts
    430
    If you backup all the time you wouldn't have to worry about "undeletion" of a file.
    good tutorial though
    I toor\'d YOU!

  5. #5
    Senior Member
    Join Date
    Sep 2001
    Posts
    121
    This was purely for knowledge. I never lost anything but now I know how to correct mistakes made by me or others... I just wanted to know!

  6. #6
    Fastest Thing Alive s0nIc's Avatar
    Join Date
    Sep 2001
    Location
    Sydney
    Posts
    1,584
    hmmm this is very interesting.. so far i only know how to undelete files in windows.. but now, ill glady add thus tut to my collection.. lol

  7. #7
    Senior Member
    Join Date
    Feb 2002
    Posts
    262
    good post tuskin, could come in handy
    aislinn, Aria, BTBAM, chevelle, codeseven, Cky, dredg, evergreen terrace, from autumn to ashes,hopesfall, hxc, luti-kriss, nirvana, norma jean, shai hulud, this hero dies, tool, underoath, zao,

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •