See interspersed On Sun, Nov 27, 2011 at 11:06 AM, Lucas Teixeira <lucas@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
