Use testdisk and gpart information to mount ext4 partition

Question

I am trying to recover the ext4 partition table of a 2TB disk, where I have 900.000 files. I have cloned the original HD and now I am working on the cloned HD. And I am running Parted Magic Live CD.

With testdisk I got what it looks like the original deleted partition:

Disk /dev/sdd - 2000 GB / 1863 GiB - CHS 243201 255 63
Partition Start End Size in sectors
>P Linux 0 1 1 243200 254 61 3907024000 [Duo]

Anybody can help me to read this numbers? As far as I know, I can use this data with the mount command and, if everything goes right, have access to the files in order to start a file transfer, can't I?

According to this man page, I can use data extracted from testdisk to help me fix the partition:

"Now using the value given by TestDisk, you can use fsck to repair your ext2/ext3 filesystem. I.E. if TestDisk has found a superblock at block number 24577 and a blocksize of 1024 bytes, run:"

# fsck.ext3 -b 24577 -B 1024 /dev/hda1

But I don't know how exactly.

By the way, here it goes some more useful data from gpart:

# gpart -gv /dev/sdd

dev(/dev/sdd) mss(512)
Primary partition(1)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 1907726mb #s(3907024000) s(63-3907024062)
   chs:  (0/1/1)-(1023/254/63)d (0/0/0)-(0/0/0)r
   hex:  00 01 01 00 83 FE FF FF 3F 00 00 00 80 74 E0 E8

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   hex:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Begin scan...
Possible partition(Linux ext2), size(1734848mb), offset(2mb)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 1734848mb #s(3552968704) s(4096-3552972799)
   chs:  (1023/255/0)-(1023/255/0)d (0/0/0)-(0/0/0)r
   hex:  00 FF C0 FF 83 FF C0 FF 00 10 00 00 00 00 C6 D3

According to this post I can use this information to help me:

"This time I got something useful. The s(63-117258434) part shows the starting sector, which is 63. A sector is 512 bytes, so the exact starting offset of the partition is 32256. So to mount this partition, just issue:"

mount -o loop,ro,offset=32256 /storage/image/diskofperson.dd /mnt/recovery

"And voilá, access to the filesystem has been obtained."

/storage/image/jdiskofperson.dd on /mnt/recovery type vfat (ro,loop=/dev/loop0,offset=32256)

Any help would be great.

Solution

I don't know if this will help...

If you get to the point where testdisk recognizes the partition, you should be able to select it and choose a menu option that will drill down into the structure and show the files. From here, there is an option to copy the files.

However, if you go back to the point where the partition you want is recognized, you should see an option on the screen to [w]rite, which writes a new partition table to the disk. This will (should) give you your recovered partition, and maybe som other bogus (best guess) partitions. At that point, copy your data and fix the disk as needed.

I'm not clear on all of the details, as I've only done this once. But testdisk recovered an NTFS partiton that I needed after messing up the partition table with FreeBSD's fdisk.

I didn't need anything except testdisk for the recovery, but apparently I changed the partition table from msdos to gpt when I made the initial device type selection in testdisk, so I ended up copying my data and reformatting the disk.

Comments

[lotk]

Thank you. Did you ran "deep seach"? Did you have to wait till the end of it? Or did you stop as soon as the partition that you knew it was yours appeared?

[Joe Internet]

I started doing the deep search, and cancelled it after it hit ~1K of 30K sectors(?), noticed the partition that I wanted, then decided to just run the deep search anyways. I don't think that I really needed to do the the DS, since the partition was picked up in the quick scan, which is where I recovered from.