Ext4 newbie trying to recover its partition table

Ext4 newbie trying to recover its partition table

[Lucas Teixeira]

Hello,

For more than a year I've been trying to recover data from a harddisk
of mine. I have really important personal files there, and I would
like to recover it myself, as I don't know of any recovering service
that I would trust to analyze ext4 partitions.

I don't know if anyone here even has the time to read my diagnosis
(pasted below).

**I would like good resources and tips to learn ext4 structure and
dive into e2fsprogs source code, in order to recover the files in my
misteriously lost partitions.**

My C experience is limited to CRUD programs, linked lists and search
trees (learned at college, before I dropped out), but I am determined
to learn what is needed.

Thank you very much, and sorry for the sometimes confusing english
(I'm from Brazil)

I'm pasting here what I said at reddit.com a year ago:


	TL;DR: The partition table that I recovered with TestDisk say that
	my three ext4 partitions begin exactly 316 bytes before they really
	begin. I don't know how to make a partition table that says exactly
	where it starts. (see fdisk output after the jump

	Hello,

	I have a Seagate Barracuda ST31000333AS HD (1TB of storage), and I
	recently bought an external case for it. It was already formatted with
	3 ext4 partitions.

	The last thing I remember is deleting a HFS partition (it has
	something to do with my love's Macbook), and then... the partition
	table was gone.

	I tried some tools to recover the partition table, and I finally
	thought that TestDisk got it right... well, it almost did.

	The sizes and positions of the recovered partitions seemed just right,
	but I couldn't mount it. And the type of the partitions in this new
	table was ext3, not ext4.

	After a lot of hexdump's and dd's, I learned a few things about
	partition tables *and* (sort of) discovered the problem:

	    lucas@blackie:~$ sudo dd if=/dev/sdc1 of=/tmp/with_offset ibs=1
	skip=316 count=1048576     /dev/null lucas@blackie:~$ file
	/tmp/with_offset /tmp/with_offset: Linux rev 1.0 ext4 filesystem data,
	UUID=d94f8233-7b02-4d9e-a20a-18831225c990, volume name "todomundo"
	(extents) (large files) (huge files)

	What I'm doing here is copying the the first megabyte of the partition
	with an offset of 316 bytes. The result is recognized as the original
	partition. This happens with all the three ext4 partitions that are in
	the disk.

	But partition tables deal with cylinders and sectors, not bytes. I
	can't put the right address in the table with any of these two units.

	I didn't mess with disk geometry at any point of this story. Anyway, I
	don't know if TestDisk changes the geometry without warnings, so the
	geometry may be wrong. The geometry of the disk *right now* is:

	    255 heads, 63 sectors/track, 121601 cylinders Sector size
	(logical/physical): 512 bytes / 512 bytes

	I downloaded the HD manual, and it says that the default geometry is:

	    Heads: 6 Discs: 3 Bytes per sector: 512 Default sectors per track:
	63 Default read/write heads: 16 Default cylinders 16,383

	But when I try to feed TestDisk with this information, it says that my
	HD has 8455MiB, which is not true.

	I have an intermittent connection with the Internet (I have no
	Internet at home, and I usually have to take a bus or walk ~30min to
	access it), but I did my homework: applied my google fu, flirted with
	hexdump and dd, RTFM... I have no idea what to do.

	### fdisk -l -u: ###

	    Disco /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63
	sectors/track, 121601 cylinders, total de 1953525168 setores Unidades
	= setores de 1 * 512 = 512 bytes Sector size (logical/physical): 512
	bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
	Identificador do disco: 0x000e09b9
	
	    Dispositivo Boot Início Fim Blocos Id Sistema /dev/sdc1
	63  1232731709   616365823+  83  Linux /dev/sdc2   *  1234675575
	1646325134   205824780   83  Linux /dev/sdc3      1646325135
	1953520064   153597465   83  Linux
l
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ext4 newbie trying to recover its partition table

[Greg Freemyer]

See interspersed

On Sun, Nov 27, 2011 at 11:06 AM, Lucas Teixeira
<lucas@lucasteixeira.com> wrote:
> Hello,
>
> For more than a year I've been trying to recover data from a harddisk
> of mine. I have really important personal files there, and I would
> like to recover it myself, as I don't know of any recovering service
> that I would trust to analyze ext4 partitions.

x-ways forensics supports ext4, and recovery experts work from a
"image" of your drive, so they should not cause any non-recoverable
damage.

(I do computer forensics for a living.  I use X-Ways primarily to do
my work, but your right, I rarely see a ext4 filesystem to analyse.)

If this is really valuable info, the first thing you should do is make
a "image" of the drive:

You'll need a second disk with enough freespace to hold the entire
original disk, then its just:

dd if=/dev/sdx of=image_file bs=4K conv=noerror,sync

bs=4k I just a speed optimization thing
noerror says not to abort on a bad block
sync says if there is a bad block, output nulls to fill it up.  That
is very important.

X-ways can work directly from that image, but it costs about $1K (US)
and further it may not work well for this case.

Once you have that backup, you can try gpart?  I think it is available
in most distros and can try to rebuild a partition table.

(I'd separately backup just sector 0 before I tried gpart, then if you
don't like the results you can put it back.)

Also, I personally would install the "sleuthkit" package.  It has lots
of command line tools designed to work with images like the above.

Here's one tool that may help:

http://wiki.sleuthkit.org/index.php?title=Mmls

sleuthkit is packaged by at least a few of the distros.

> I don't know if anyone here even has the time to read my diagnosis
> (pasted below).
>
> **I would like good resources and tips to learn ext4 structure and
> dive into e2fsprogs source code, in order to recover the files in my
> misteriously lost partitions.**
>
> My C experience is limited to CRUD programs, linked lists and search
> trees (learned at college, before I dropped out), but I am determined
> to learn what is needed.
>
> Thank you very much, and sorry for the sometimes confusing english
> (I'm from Brazil)
>
> I'm pasting here what I said at reddit.com a year ago:
>
>
>        TL;DR: The partition table that I recovered with TestDisk say that
>        my three ext4 partitions begin exactly 316 bytes before they really
>        begin. I don't know how to make a partition table that says exactly
>        where it starts. (see fdisk output after the jump
>
>        Hello,
>
>        I have a Seagate Barracuda ST31000333AS HD (1TB of storage), and I
>        recently bought an external case for it. It was already formatted with
>        3 ext4 partitions.
>
>        The last thing I remember is deleting a HFS partition (it has
>        something to do with my love's Macbook), and then... the partition
>        table was gone.
>
>        I tried some tools to recover the partition table, and I finally
>        thought that TestDisk got it right... well, it almost did.
>
>        The sizes and positions of the recovered partitions seemed just right,
>        but I couldn't mount it. And the type of the partitions in this new
>        table was ext3, not ext4.
>
>        After a lot of hexdump's and dd's, I learned a few things about
>        partition tables *and* (sort of) discovered the problem:
>
>            lucas@blackie:~$ sudo dd if=/dev/sdc1 of=/tmp/with_offset ibs=1
>        skip=316 count=1048576     /dev/null lucas@blackie:~$ file
>        /tmp/with_offset /tmp/with_offset: Linux rev 1.0 ext4 filesystem data,
>        UUID=d94f8233-7b02-4d9e-a20a-18831225c990, volume name "todomundo"
>        (extents) (large files) (huge files)
>
>        What I'm doing here is copying the the first megabyte of the partition
>        with an offset of 316 bytes. The result is recognized as the original
>        partition. This happens with all the three ext4 partitions that are in
>        the disk.
>
>        But partition tables deal with cylinders and sectors, not bytes. I
>        can't put the right address in the table with any of these two units.

cylinders are extremely rarely used anymore.  I think any drive over
4GB cannot be accessed via CHS.  Focus exclusively on sectors.

>        I didn't mess with disk geometry at any point of this story. Anyway, I
>        don't know if TestDisk changes the geometry without warnings, so the
>        geometry may be wrong. The geometry of the disk *right now* is:
>
>            255 heads, 63 sectors/track, 121601 cylinders Sector size
>        (logical/physical): 512 bytes / 512 bytes

None of the tools will pay attention to head/cylinders/etc.

Al that matters is sectors from the start of the drive.

>        I downloaded the HD manual, and it says that the default geometry is:
>
>            Heads: 6 Discs: 3 Bytes per sector: 512 Default sectors per track:
>        63 Default read/write heads: 16 Default cylinders 16,383

Don't worry about geometry.

>        But when I try to feed TestDisk with this information, it says that my
>        HD has 8455MiB, which is not true.
>
>        I have an intermittent connection with the Internet (I have no
>        Internet at home, and I usually have to take a bus or walk ~30min to
>        access it), but I did my homework: applied my google fu, flirted with
>        hexdump and dd, RTFM... I have no idea what to do.
>
>        ### fdisk -l -u: ###
>
>            Disco /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63
>        sectors/track, 121601 cylinders, total de 1953525168 setores Unidades
>        = setores de 1 * 512 = 512 bytes Sector size (logical/physical): 512
>        bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes
>        Identificador do disco: 0x000e09b9
>
>            Dispositivo Boot Início Fim Blocos Id Sistema /dev/sdc1
>        63  1232731709   616365823+  83  Linux /dev/sdc2   *  1234675575
>        1646325134   205824780   83  Linux /dev/sdc3      1646325135
>        1953520064   153597465   83  Linux
> l

Good Luck
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ext4 newbie trying to recover its partition table

[Ted Ts'o]

On Sun, Nov 27, 2011 at 02:06:44PM -0200, Lucas Teixeira wrote:
> Hello,
> 
> For more than a year I've been trying to recover data from a harddisk
> of mine. I have really important personal files there, and I would
> like to recover it myself, as I don't know of any recovering service
> that I would trust to analyze ext4 partitions.
> 
> I don't know if anyone here even has the time to read my diagnosis
> (pasted below).
> 
> **I would like good resources and tips to learn ext4 structure and
> dive into e2fsprogs source code, in order to recover the files in my
> misteriously lost partitions.**

Have you tried using the program "gpart"?  It's the go-to program for
recovering damaged partition tables in my book.

						- Ted