Fedora11, rescue partition (info) after installation failure

scmbg · 07-24-2009, 01:09 AM

History:

We start with the installation of Fedora 11 in the database's laboratory (replacing the Fedora 9 partition), everything was fine, but ...

In a computer we have important information (in Fedora's 9 partition) so when the program installation begins to create a new file system (for Fedora 11 in) on that partition, the assistant turn off the computer hopping nothing has been erased.

And of course, we lost the partition.

Now, we only see 3 partitions, 2 NTFS, a RAW only 200MB when it should be a ext3 - 10GB; besides the SWAP also disappeared.

My question is, there is any way, tool, hack to access the information.

Initially the HD has this layout:

Partition 1: NTFS -> 19.5GB
Partition 2: NTFS -> 10GB
Partition 3: ext3 -> 10GB
Partition 4: swap -> 512Mb

And now only see:

Partition 1: NTFS -> 19.5GB
Partition 2: NTFS -> 10GB
Partition 3: RAW -> 200Mb

The rest appear like unallocated space.

I really need you help.

Simon Bridge · 07-24-2009, 02:26 AM

Quote:

the assistant turn off the computer hopping nothing has been erased.

Ah - the old "pray" method of backups. Naturally the labs automatic backup policy means that only a few hours data was lost?

There are lots of freeware and shareware products claiming to be able to undelete a deleted partition, even for ext3.

http://shareme.com/showall/recover-d...partition.html
... while this task should be physically possible (provided nothing else has happened), I don't know that any of these are any good.

There are a great deal of high quality linux-based forensics tools.
I just have not found anyone trying to recover data from a deleted partition before.

Christophe GRENIER · 07-24-2009, 07:42 AM

TestDisk should be able to recover your partition
You can install it using
- yum install testdisk
or
- wget http://www.cgsecurity.org/testdisk-6...inux26.tar.bz2
- tar xvjf testdisk-6.12-WIP.linux26.tar.bz2
- cd testdisk-6.12-WIP/linux
- sudo ./testdisk_static
More information can be found at http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

scmbg · 07-25-2009, 10:04 AM

We try "testdisk", with a deep search and we found the partition, but the software cant find the superblock, so i think that we need a forensic tool, to search "byte by byte" to find lost files.

So, anybody have a suggestion?

Thanks!

linus72 · 07-25-2009, 10:13 AM

Mmmm
what about dd rescue?
or ?
have alook at theser
http://www.e-evidence.info/other.html

http://www.data-recovery-software.ne...io/index.shtml

jschiwal · 07-25-2009, 02:12 PM

I would recommend creating an image backup of the deleted partition, and saving it to an external drive. Perhaps two backups, one you can run forensic tools on. If one tool modifies what is on the disk, the next tool may fail as a result.

After an installation, run "sudo /sbin/fdisk -l" and "sudo /sbin/fdisk -lu" and print out the results. They can make it easier to recreate an old partition table. The -lu option uses a block size of 512 for the results. Using 1024 byte blocks or cylinders instead could recreate a partition at the wrong place, and make it look corrupt. Since this was the first partition being reformated, I don't think that would help.

I took a look at two separate ext3 filesystems on my laptop to see if they had the same backup superblocks:

Code:

dumpe2fs  /dev/sda6 | grep Backup
dumpe2fs 1.41.1 (01-Sep-2008)
  Backup superblock at 32768, Group descriptors at 32769-32770
  Backup superblock at 98304, Group descriptors at 98305-98306
  Backup superblock at 163840, Group descriptors at 163841-163842
  Backup superblock at 229376, Group descriptors at 229377-229378
  Backup superblock at 294912, Group descriptors at 294913-294914
  Backup superblock at 819200, Group descriptors at 819201-819202
  Backup superblock at 884736, Group descriptors at 884737-884738
  Backup superblock at 1605632, Group descriptors at 1605633-1605634
  Backup superblock at 2654208, Group descriptors at 2654209-2654210
  Backup superblock at 4096000, Group descriptors at 4096001-4096002
qosmio:~ # dumpe2fs  /dev/sda7 | grep Backup
dumpe2fs 1.41.1 (01-Sep-2008)
  Backup superblock at 32768, Group descriptors at 32769-32773
  Backup superblock at 98304, Group descriptors at 98305-98309
  Backup superblock at 163840, Group descriptors at 163841-163845
  Backup superblock at 229376, Group descriptors at 229377-229381
  Backup superblock at 294912, Group descriptors at 294913-294917
  Backup superblock at 819200, Group descriptors at 819201-819205
  Backup superblock at 884736, Group descriptors at 884737-884741
  Backup superblock at 1605632, Group descriptors at 1605633-1605637
  Backup superblock at 2654208, Group descriptors at 2654209-2654213
  Backup superblock at 4096000, Group descriptors at 4096001-4096005
  Backup superblock at 7962624, Group descriptors at 7962625-7962629
  Backup superblock at 11239424, Group descriptors at 11239425-11239429

They do. Would the location of one of the later ones be useful to you?

scmbg · 07-25-2009, 06:56 PM

Ok, i use photorec from TestDisk, and only got cuted, trimed and wrong sized files, like 0Kb txt, and 200Mb png.

Now i gonna try linus72 and jschiwal suggestions.

jschiwal thanks for that info; i keep trying to make it happen.

Christophe GRENIER · 07-26-2009, 05:36 AM

Quote:

Originally Posted by scmbg

We try "testdisk", with a deep search and we found the partition, but the software cant find the superblock, so i think that we need a forensic tool, to search "byte by byte" to find lost files.

So, anybody have a suggestion?

Thanks!

If TestDisk has found the partition, write the partition table if it's not already the case. In Advanced, select the partition and choose SuperBlock. Run "fsck.ext3 -b superblock -B blocksize device" with the values given by TestDisk.

Simon Bridge · 07-27-2009, 03:20 AM

ext3 partitions store multiple copies of the superblock - but the only software I have heard of taking advantage of this forensically is ext3grep.

I have no idea if this will be useful here. However, it used to be almost routine to use dd to clone the drive and use grep to look for file markers ... going byte by byte basically. It is labour intensive which is why most people just try to rebuild the lost data from other sources.

Um - unless they are doing industrial espionage of course

scmbg · 07-28-2009, 05:32 PM

Thanks for all your help, I keep trying.

In the weekend i was worked with an image, so now i'm in the lab and have a fresh copy and every test is make over a fresh image.

First, TestDisk detect the partition and i write the info, so now i have a good felling/view, the original Table was:

Code:

Partition 1: NTFS -> 19.5GB
Partition 2: NTFS -> 10GB
Partition 3: ext3 -> 10GB
Partition 4: swap -> 512Mb

And after the TestDisk

Code:

Partition 1: NTFS -> 19.5GB
Partition 2: NTFS -> 10GB
Partition 3: ext3 -> 10GB

The swap dosent appear... Anyway, I was used the PhotoRec and only have trimed files, but someones was OK. Then i use R-Linux, this give me better results, recover a little more information.

Then run the fdisk tool with the -l and -lu parameters ans this is the output, (note this information come from a old kernel, system (Mandrake 10 Live).

Code:

# fdisk -lu

Disk /dev/scsi/host1/bus0/target0/lun0/disc: 1000 MB, 1000341504 bytes
255 heads, 63 sectors/track, 121 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                                 Device Boot    Start       End    Blocks   Id  System
/dev/scsi/host1/bus0/target0/lun0/part1             1       121    971901    b  Win95 FAT32

Disk /dev/ide/host1/bus1/target0/lun0/disc: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                                Device Boot    Start       End    Blocks   Id  System
/dev/ide/host1/bus1/target0/lun0/part1   *         1      1795  14418306    7  HPFS/NTFS
/dev/ide/host1/bus1/target0/lun0/part2          1796      3032   9936202+   7  HPFS/NTFS
/dev/ide/host1/bus1/target0/lun0/part3          3440      4865  11454345   83  Linux

Code:

# fdisk -lu

Disk /dev/scsi/host1/bus0/target0/lun0/disc: 1000 MB, 1000341504 bytes
255 heads, 63 sectors/track, 121 cylinders, total 1953792 sectors
Units = sectors of 1 * 512 = 512 bytes

                                 Device Boot    Start       End    Blocks   Id  System
/dev/scsi/host1/bus0/target0/lun0/part1            63   1943864    971901    b  Win95 FAT32

Disk /dev/ide/host1/bus1/target0/lun0/disc: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders, total 78165360 sectors
Units = sectors of 1 * 512 = 512 bytes

                                Device Boot    Start       End    Blocks   Id  System
/dev/ide/host1/bus1/target0/lun0/part1   *        63  28836674  14418306    7  HPFS/NTFS
/dev/ide/host1/bus1/target0/lun0/part2      28836675  48709079   9936202+   7  HPFS/NTFS
/dev/ide/host1/bus1/target0/lun0/part3      55247535  78156224  11454345   83  Linux

Now, the things about the superblock...

When i try to print informacion about them with dumpe2fs but an error appered.

Code:

# dumpe2fs /dev/hdc4
dumpe2fs 1.34 (25-Jul-2003)
dumpe2fs: Bad magic number in super-block while trying to open /dev/hdc4
Couldn't find valid filesystem superblock.

Then i use the information given by jschiwal, and try those superblocks but...

Code:

fsck.ext3 -b 32768 -B 512 /dev/hdc4
e2fsck 1.34 (25-Jul-2003)
fsck.ext3: Bad magic number in super-block while trying to open /dev/hdc4

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

So i think that the partition rescued was the new, created by Fedora 11, not the old one (Fedora 9), finally, Testdisk cant find the superblocks, but R-Linux give me a lot of information about them.

Display sectors where find superblocks. for example.

Superblock at sector 1985094, position 1011252224 (964.405MB) away from the partition's start.

What can i do with this info?

Update

It is time to test ext3grep.

Thanks!