Data Recovery, debugfs, damaged drives - is there a better OSS tool?
 

This is an end of the year surprise. I had a pata drive with some backup data on it, that I was going to update the filesystem on. I used another drive to archive the important data from it, but had inadvertently deleted some data from a typo. This gave me a chance to try the OSS data recovery tool "debugfs" with the "undelete" option. The man page was sparse on how to use it. I was able to recover the filenames, copy them to the other drive, and continue...but they turned out to be empty files. Then, the pata drive set for the filesystem update crashed. On reboot, the backup drive is not seen anymore by the BIOS. Checked, and rechecked the cables. The pata drive is seen, but parted, gparted, and fdisk all show it as a 32G drive. This pata drive has bad blocks on it.

While I was new to using debugfs, I read the man pages for it. Are there other OSS tools for data recovery? What about the low level format on drives with bad blocks (input/output errors)?

Most drives will not allow you to do a low level format no matter what the software you're using tells you. This is done at the manufacturer and the firmware will block any further attempts.
There is a software called SpinRite which can re-map bad sectors by making multiple passes if required over bad sectors to read the data within and re-write/reallocate the data to spare sectors, allowing you to recover as much if not all data. It is not OSS, but you won't find anything comparable in the OSS department.

You may not need to go beyond SpinRite. If you read articles about it you'll soon find it's a miracle worker when it comes to saving drives, not just the data written to it. In most cases, you can run the drive as slave and read it's entire contents after using SpinRite, if it's bootable, most often you can boot it also.

I've never used debugfs to recover data, it sounds similar to the sleuthkit which can give detailed information on deleted files such as it's location (first inode), which blocks it uses, etc. Then you need to get to know tools like dd to recover files from this information.

If you have testdisk installed or are using a live CD with testdisk included, you can issue command: photorec from CLI to recover many common file types regardless of the state of the file system by telling photorec to scrub the entire device instead of just a partition if the OS does not report it's size properly. But it is best to run SpinRite first if you have bad blocks.

Keep in mind, most people with no experience in this field end up loosing their data for good by trying to take the cheap way out, then end up spending more than they would have for data recovery services in the end if the data is worth paying for it, and still get nothing because of all f***ing around they did before taking it to a professional rendering it un-recoverable.

ddrecover will allow you to just copy the whole thing over to somewhere else, and will also allow you to specify a start and stop position. It is like dd only handles bad blocks in a sane manner. The reason debugfs did not recover anything is probably because your filesystem was ext3 and not ext2. ext3 filesystems clear all of the inode info that the undelete uses to restore the file. So although it knew the files inode, and its name, that's about it. It was not able to determine on its own where the data blocks were located. File recovery from ext3 filesystems is a very tough process. If you really need to do it, I would look at the ext3grep tool, but you must have an intense familiarity with the ext3 and ext2 filesystem to even begin to use it effectively. It is not a magic bullet.

Thanks
 

Hi I have a 1 TB usb disk and I screwed up the partition tables.
Currently I had three formatted partitions and the rest is unused space.
As you suggested, Junior Hacker, I used testdisk to restore two of the three partitions and photorec to recover ALL of my files on the unrecoverable partition. I recovered almost 6000 photos and 550 mp3s.

Thanks for your input.
okos

I started a disk recovery process before reading these replys. Next time I will take a look at these other options mentioned. I have run a badblocks option on the drive, and it went through 80% of the drive in about a day and a half, but then it seemed to hit a roadblock and continued to run, and run with incredibly slow progress. It has ran for more than a week now, with no end in sight. For the first 80% of the badblocks run, it was showing up in the list of high cpu use, in spurts. Now it does not show up. I reniced it, but don't see anything changing. Is there a way that I can get it back to the normal progress that it was at during the first day and a half? What changed that made it progress so slowly? The drive is a few hundred gigs.

I read the documentation on "badblocks" and it seems to perform the low level recovery. While it may not be the same as what a manufacturer can do, it is supposed to recover blocks.
Ext3 is supposed to be easier to recover than ext2 because it has a journal? For instance, if you read about "shred" it claims that it does not work as well on journaling filesystems and that recovery of files after a shred operation is possible on journaling filesystems. It does not say what tools will do that. In terms of the ext3 recovery, next time I can try the tools you mentioned and read up on ext3 filesystem. For recovery purposes, if I disable the journal, can I then use ext2 filesystem recovery?

This brings the question to me, that what ext3 data recovery methods are there? Ext3 has a journal, and that is supposed to make it easier to recover data and lost files. The journal is supposed to have information to assist in this process. Anyone used the ext3 journal in this way?