LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   recovering files from a formatted ext3 drive... possible? (http://www.linuxquestions.org/questions/linux-general-1/recovering-files-from-a-formatted-ext3-drive-possible-672621/)

oskar 09-26-2008 09:31 PM

recovering files from a formatted ext3 drive... possible?
 
So that was probably the worst user-error I've ever made. I have no idea how it could have possibly happened, but obviously it did happen.
Somehow I managed to mix up my usb stick and data drive and formatted the latter to fat32 and copied some data over. Honestly I do not. I always double check everything.

Now I don't have the slightest idea how ext3 works, and I don't want to know. Just: is there any chance I can get these files back?... any at all? 99% of the drive have not been touched, so technically all the files are there. What I don't know is if there is a way to make sense of that data without whatever it is that is in the first couple of sectors of an ext3 partition.

Last backup has been quite a while, so help would be very much appreciated.

Peacedog 09-26-2008 10:31 PM

Hi oskar, This is about the only thing I've seen that could help you. Undelete ext3. I suggest reading the entire page and the mailing list archives.
Good luck. ;-)

jailbait 09-26-2008 11:43 PM

Quote:

Originally Posted by oskar (Post 3292955)

What I don't know is if there is a way to make sense of that data without whatever it is that is in the first couple of sectors of an ext3 partition.

Before you start back up the damaged partition using dd. You may make things worse while trying to fix the partition and you can always revert to the dd copy if you screw things up even more.

The ext3 file system has some redundancy built in. There is a superblock at block 0 which is the basic inode for the whole file system. The information in this superblock is repeated periodically in the partition. So you can try to recreate the ext3 file system by using the fsck command and telling fsck to use the superblock at 32768 or 98304 or whatever superblock is not overwritten by fat32.

The trick is finding a superblock not overwritten when you formated as fat32. The best program to look for surviving superblocks is testdisk. Testdisk is designed to recover a broken partition table. It also can be used to find superblocks.

See:

man dd

man fsck

man testdisk

---------------------
Steve Stites

H_TeXMeX_H 09-27-2008 04:31 AM

If all of the above fail, you can still recover some files with foremost, whatever files might still be on there and have their headers intact.

pinniped 09-27-2008 07:05 AM

Most data should be recoverable since an ext2/3 format only rewrites inodes (and for ext3 the journal spaces). Lucky it's not NTFS which wants to waste your time putting 0 in all positions.

oskar 10-13-2008 03:43 PM

Thanks for the replies so far. Unfortunately I'm near completely incompetent when it comes to drive geometry.
I let testdisk run. After a test run it sais it found a "bad SUN partition" (which is what I told it, so no idea what it actually found)... I can choose to recreate the partition, but this doesn't seem any different from rewriting the partition with fdisk: Starting at first cylinder, ending at last, label:83, and write.

But it says:
"Function write_part_sun not implemented"
when I click "write"

As I understand it, just recreating the partition with fdisk won't help - it would if I hadn't overwritten anything.
So I need to do that superblock thing, but I couldn't find anything on that in the manuals, and the man pages are of no help (no mention of how to find or recreate superblocks)
I tried googling for it for about half an hour, but since I don't really know what I'm looking for, I would very much appreciate if someone could point me in the right direction.

How do I find an intact superblock, and how do I use it to recreate the old ones?

The best idea I've got so far: just recreate the partition with fdisk and let fsck figure out the rest. :D

appending the testdisk.log... doesn't look terribly interesting, but it can't hurt:


Code:

Mon Oct 13 20:38:00 2008
Command line: TestDisk

TestDisk 6.8, Data Recovery Utility, August 2007
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Linux version (ext2fs lib: 1.40.8, ntfs lib: available, reiserfs lib: none, ewf lib: none)
Using locale 'en_US.UTF-8'.
Hard disk list
Disk /dev/sda - 160 GB / 149 GiB - CHS 19457 255 63, sector size=512
Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512

Disk /dev/sdb - 500 GB / 465 GiB
Partition table type: Sun

Analyse Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63
Current partition structure:
Bad SUN partition

search_part()
Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63

Results
List of partition type
01 Boot                06 SunOS stand          82 Linux swap         
02 SunOS root          07 SunOS var            83 Linux native       
03 SunOS swap          08 SunOS home          8e Linux LVM         
04 SunOS usr            09 SunOS alt.          fd Linux raid autodetect
05 Whole disk          0a SunOS cachefs       
  D Linux native            0  0  1 60800 254 63  976768065

interface_write()
 2 P Whole disk              0  0  1 60800 254 63  976768065
 0 P Linux native            0  0  1 60800 254 63  976768065
write!
Function write_part_sun not implemented
You will have to reboot for the change to take effect.

Analyse Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63
Current partition structure:
Bad SUN partition

search_part()
Disk /dev/sdb - 500 GB / 465 GiB - CHS 60801 255 63
Search for partition aborted

Results

interface_write()
 2 P Whole disk              0  0  1 60800 254 63  976768065
simulate write!

TestDisk exited normally.


jailbait 10-13-2008 03:52 PM

Quote:

Originally Posted by oskar (Post 3308970)



How do I find an intact superblock, and how do I use it to recreate the old ones?


You tell fsck where there is a superblock. Then fsck looks where you say and decides whether that superblock is valid or not. If not you try another superblock.

For a partition the size of your partition the superlocks are spaced out every 32768 blocks. So you have superblocks at 0, 32768, 65536, and so on.

see:

man fsck

---------------------
Steve Stites

oskar 10-13-2008 03:55 PM

At the very bottom of this page is a guide to what seems to apply to my problem:
http://www.cgsecurity.org/wiki/Data_Recovery_Examples

Quote:

Recovery of reformated partition

If the partition has been reformated to another filesystem (FAT32 formated as NTFS or vice-versa),

* run TestDisk,
* select the harddisk, the partition type
* choose Advanced
* select the partition
* choose Type,
* enter the value corresponding to the previous filesystem
* choose Boot
* choose RebuildBS
* List
* If you can see your files, choose Write and confirm
* In Analyse, choose to rewrite the partition with the correct partition type.

Return to TestDisk main page
But when I get to point 4 "select the partition", There is no partition for me to select. But the fat32 partition is still there. I haven't made any changes to the drive so far - the testdisk write failed.
Code:

  Device Boot      Start        End      Blocks  Id  System
/dev/sdb1  *          1      60800  488375968+  b  W95 FAT32


oskar 10-25-2008 06:23 PM

Quote:

Originally Posted by jailbait (Post 3308979)
You tell fsck where there is a superblock. Then fsck looks where you say and decides whether that superblock is valid or not. If not you try another superblock.

For a partition the size of your partition the superlocks are spaced out every 32768 blocks. So you have superblocks at 0, 32768, 65536, and so on.

see:

man fsck

---------------------
Steve Stites

Sorry... didn't see your reply. Got wedged in there between my posts.

The problem is that it is currently a Fat32 partition. Do I just recreate the partition table with fdisk, and then use fsck to fix it?


All times are GMT -5. The time now is 01:17 PM.