Recovering a deleted file on ext3... almost there!

Hi all,

So, I deleted a file I need using rm on an ext3 partition that I didn't mean to delete. When I run debugfs -w, cd into the directory I deleted the file in, and do a ls -d, I see the deleted inode for the file that I'm trying to recover. So, I have all of the information I think I need to recover the file, but I just don't know the next step... what do I do from here? The disk hardly active at all, so I'm sure that the data is still there.

Thanks in advance!

Abe

Hrm... maybe I don't have all of the information I need to recover the file. While I do have the inode number, it appears that the information in the inode is zerod when you delete a file on ext3 as opposed to just being marked as deleted such as on ext2.

Any suggestions?

Creating a dd image now... going to try foremost on it.

I have heard that it is next to impossible to recover deleted files on ext3 as apposed to ext2. I belive that there are some data recovery tools out there that might help you but I've never actually attempted it myself. You can try your luck on google and see what kind of utilities you can find.

regards,
...drkstr

Q: How can I recover (undelete) deleted files from my ext3 partition? Actually, you can't! This is what one of the developers, Andreas Dilger, said about it: In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as "deleted" and leaves the block pointers alone. Your only hope is to "grep" for parts of your files that have been deleted and hope for the best.

Source: http://batleth.sapienti-sat.org/proj.../ext3-faq.html

Ok, I got it. THAT was a process I don't want to go through again.

I used debugfs to determine the inode of the file that was deleted, then used that information to determined which block group the data belonged to, then used that information to determine which block range was assigned to that block group, sucked those blocks out using dls from the TSK, then used foremost (after monkeying with the configuration file for a while) to extract the data (a process known as data carving).

There is still some cleanup work to be done, and not all information was recovered, but the majority of it was. Now, my friends, it's time for a beer. Cheers!

EDIT: I am tagging my original post "dumbass", as it most definitely deserves to be.

Well, you said it, not one of us.

BTW, I added "undelete, ext3, file, recovery" to the tags.

Also, thanks for posting back the synopsis of your solution.

Hi!

I realized that I did rm -rf /home/mydirectory on Monday morning before enough coffees had been taken.
I upgraded from Suse 10.1 to Suse 10.2 during the weekend. The file system is ext3.

From the internet searches and old threads, it is certain that it is almost impossible to recover deleted ext3 file directories. But I guess and hope that as IT-related technologies are developing so fast these days there are some way of recovering the removed ext3 files, unless they have not overwritten, although the inodes of deleted ext3 files got zeroes.

Could someone suggest most recent best ways to recover deleted ext3 files? I can resort to any professional recovery companies or any softwares, if availabe.

Is the formost program worthwhile to recover the deleted files efficiently?

Thank you very much.

dsheen

I recently had a user move (from Windows) a path with about 1T of files under it. Realizing the mistake, the transaction was cancelled mid-way. For some odd reason, the files no longer showed up on the Samba server. I had to dd the partition over the network (I used ssh, as I couldn't figure out how to use nc / netcat for my platform -- CentOS5). Also, it wasn't such a bright idea to compress the partition, because there wasn't space to uncompress it later. I just let dd do its thing over night on a 700GB partition.

Once I had the image, I booted into Helix, a live Linux computer forensics distribution that looked promising. I was disappointed with Autopsy, as I was trying to recover paths, not just files, and it seemed to be unable to show me the contents of a deleted path.

However, Foremost looks like an awesome tool. One thing that doesn't stand out in the documentation (the man) is that it is possible to use it to recover Excel files (as Foremost has an ole type). I just pointed it at the 700 GB image and turned it loose.

The whole reason I had to go through all this is because the backup scripts were under repair, and happened to be failing quietly when this happened. I'll be taking extra pains to make sure that doesn't happen again.

Originally Posted by abegetchell Ok, I got it. THAT was a process I don't want to go through again. I used debugfs to determine the inode of the file that was deleted, then used that information to determined which block group the data belonged to, then used that information to determine which block range was assigned to that block group, sucked those blocks out using dls from the TSK, then used foremost (after monkeying with the configuration file for a while) to extract the data (a process known as data carving). There is still some cleanup work to be done, and not all information was recovered, but the majority of it was. Now, my friends, it's time for a beer. Cheers! EDIT: I am tagging my original post "dumbass", as it most definitely deserves to be.

Abegetchell,

Can you explain the procedure you followed, after getting "the inode number of the file that was deleted" with debugfs, to "determine which block group the data belonged to" and then to "determine which block range was assigned to that block group" before extracting the data using dls from the TSK.

Tools for recovering lost files on ext3 partitions: (in order of my recommended use)

1. photorec
2. foremost
3. magicrescue
4. ripper
5. unrm
6. gET iT i sAY-giis
7. e2undel
8. ext3undel

Tools for renaming and sorting recovered files:

1. findup (from the fslint software package)
2. A wiki page of suggestions
3. jhead
4. easytag

-J_Tom_Moon_79

The Ext3 file system itself suits bad for such kind of recovery, that's why it's recommended to use Reiser or XFS for you '/home' folder (as well as to other folders where you going to have read/write). These file systems have better performamce (however this is subject to driver implementation) and better recovery perspectives.
Here we using Ext3 on boot (or boot and root) partitions only because it is 'boot loader safe'.

In case data deletion took place on Ext3, the information about deleted files may still remain in file system journal and utilities like commercial UFS Explorer version 4 (http://www.ufsexplorer.com/download_stdr.php) may pick them from there.
As last chance alternative it also searches for indirect pointers tables of larger files and in many cases may pick up good files even without inodes (but also without real names).

Please note that Ext2 (without journal) does not wipe file inodes and that's why there are better chances for recovery with many even simpler tools.

Originally Posted by J.W. Source: http://batleth.sapienti-sat.org/proj.../ext3-faq.html

- actually this applies to file system metadata itself. Yes, exactly, Ext3 driver wipes inodes immediately, however does updates through file system journal. That's why 'smart' software still may find information state before deletion took place.

By the way, this will not help against 'mkfs' because this operation is 'external' to file system and is not journalled.