Need data recovery ideas for overwritten partition

GlennsPref · 07-01-2010, 08:43 PM

SleuthKit/Autopsy is a forensic suite for recovering files, the cops use it to recover evidence.

You may not need it.

Now you have an image of the drive, try find.

Code:

find filename

type

Code:

man find 
find --help

for more help.

Regards Glenn

unSpawn · 07-02-2010, 06:27 PM

I'd suggest is running testdisk again (start with "/debug /log /dev/devicename"). It doesn't require a partition larger than the partition being recovered as GlennsPref said in post #2 as testdisk works on the disk directly. The "WD My Passport Essential 320 GB" (0) contains a drive with LBA addressing (623769600 512-byte logical blocks resulting in 319 GB) so you need to translate LBA to CHS (1) and set the values in the advanced menu before starting recovery. Calculate with these facts: A LBA drive always uses 63 sectors. Cylinders equals drive capacity divided by 63, divided by heads. Heads values are 16, 32, 64, 128, or 255 depending on drive size. So with sectors and drive capacity as constants your options are:
Cylinders: 38827 Heads: 255 Sectors: 63
Cylinders: 77352 Heads: 128 Sectors: 63
Cylinders: 154704 Heads: 64 Sectors: 63
Cylinders: 309409 Heads: 32 Sectors: 63
Cylinders: 618819 Heads: 16 Sectors: 63
As you set these options also set the block size to 512. Now do a partition recovery run and let it write out the result. Once done writing the partition table the result of checking backup superblock existence (2) from the advanced menu should confirm readability. Of course this depends on quite a few things but let's not go into that.

GlennsPref · 07-03-2010, 12:09 AM

Hmm, I did A+ for m$ NT in 2001, or some thing (edit, actually it was, sept 11 2001 occurred at the same time I was completing the course).

But I generally don't have to go that far.

But, Thanks for the reminder, win2K was a bitch to keep control of as well as have access to.

Thanks unSpawn,

The posts I have read of yours are always enlightening.

And, I realise something new I need to reference.

Cheers, and keep up the "Open Source Spirit", as I intend to.

Regards Glenn

Xotli · 07-05-2010, 04:25 PM

Quote:

Originally Posted by GlennsPref

Now you have an image of the drive, try find.

Code:

find filename

Not sure what you mean ... my disk image isn't a directory, it's just a file. find isn't going to do anything with that.

Quote:

Originally Posted by unSpawn

I'd suggest is running testdisk again (start with "/debug /log /dev/devicename"). It doesn't require a partition larger than the partition being recovered as GlennsPref said in post #2 as testdisk works on the disk directly.

Yes, but I've been scared to let anything write to the disk directly, because at this point that disk is the last best hope for my data.

So I've imaged the disk onto a bigger disk (using ddrescue, I believe; see earlier messages in this thread) and I'm running testdisk on that.

So, I've done testdisk many many times at this point, and, no matter what I do, choosing "Advanced" gets me this:

Code:

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk small_passport.img - 319 GB / 297 GiB - CHS 38827 255 63


No partition available.














[  Quit  ]
                              Return to main menu

I just tried it again as you suggested (the "/debug" switch I hadn't tried yet); same thing.

Quote:

Originally Posted by unSpawn

The "WD My Passport Essential 320 GB" (0) contains a drive with LBA addressing (623769600 512-byte logical blocks resulting in 319 GB) so you need to translate LBA to CHS (1) and set the values in the advanced menu before starting recovery. Calculate with these facts: A LBA drive always uses 63 sectors. Cylinders equals drive capacity divided by 63, divided by heads. Heads values are 16, 32, 64, 128, or 255 depending on drive size. So with sectors and drive capacity as constants your options are:
Cylinders: 38827 Heads: 255 Sectors: 63
Cylinders: 77352 Heads: 128 Sectors: 63
Cylinders: 154704 Heads: 64 Sectors: 63
Cylinders: 309409 Heads: 32 Sectors: 63
Cylinders: 618819 Heads: 16 Sectors: 63
As you set these options also set the block size to 512. Now do a partition recovery run and let it write out the result. Once done writing the partition table the result of checking backup superblock existence (2) from the advanced menu should confirm readability. Of course this depends on quite a few things but let's not go into that.

Well, I'm not sure I followed all of that, but fdisk -l tells me that the number of cylinders is 38827, which matches the first line in your list there. I tried going into the "Geometry" option of testdisk and setting those numbers (all of which it had correctly except the number of cylinders, which it had at 38828, for some reason). Then I went back to "Advanced". Same result as above.

I would love to have testdisk just recover the partition for me, so if you (or anyone!) has any other ideas for me to try, I'm definitely all ears.

unSpawn · 07-05-2010, 05:24 PM

The problem is that this is a partial account of what you've done. It is impossible to tell if you did set block size to 512, if you did a deeper search et cetera. Could you list ALL steps you took starting with the actual command line and also *attach* the testdisk.log?

If all fails you could opt for doing the desperate thing trying to goad fsck on by letting testdisk write a clean MBR to small_passport.img and then having testdisk delete the PT after which you could 'losetup /dev/loop3 small_passport.img; fdisk /dev/loop3;' and create a single primary partition spanning the whole disk, set it to be type 83. After that run 'kpartx -a /dev/loop3; ls -l /dev/mapper/loop*' and notice the full path for the "/dev/mapper/loop*" device. If there is such a device (lets call it "/dev/mapper/loop3p1"), then run 'mkfs.ext3 -n /dev/mapper/loop3p1' and note the line below "Superblock backups stored on blocks:". Starting with the last of these numbers run 'fsck.ext3 -dvy -b [numberhere] /dev/mapper/loop3p1 2>&1|tee /tmp/fsck.log'.

Xotli · 07-06-2010, 01:38 AM

Quote:

Originally Posted by unSpawn

The problem is that this is a partial account of what you've done.

I'm sorry if I'm unclear. I've tried to mention nearly all the things I've done throughout the thread.

Quote:

Originally Posted by unSpawn

It is impossible to tell if you did set block size to 512, ...

Well, blocksize is one of the things it asks for in "Geometry", and I put in the numbers you gave me (as I mentioned). Now, if there's some way I should be setting blocksize other than via "Geometry" then please let me know, because obviously I'm missing it.

Quote:

Originally Posted by unSpawn

... if you did a deeper search et cetera.

Actually, I didn't do that last time, although I did it several other times (as I mentioned here and here and here). I'll do that for this run.

Quote:

Originally Posted by unSpawn

Could you list ALL steps you took starting with the actual command line and also *attach* the testdisk.log?

Gotcha. (Weirdly, attaching the log didn't occur to me, although I suppose it should have. Obvious in retrospect. Sorry.)

Code:

[root@sharn recovery]# ll -h
total 298G
-rw-r--r-- 1 root root 6.6M 2010-07-01 09:11 photorec.log
-rw-r--r-- 1 root root 298G 2010-07-01 00:01 small_passport.img
-rw-r--r-- 1 root root  163 2010-06-30 23:33 sp_ddr.log
[root@sharn recovery]# testdisk /debug /log small_passport.img

It asks me to pick a media, with the image file the only choice. I proceed.

It asks me what partition type, I choose Intel.

Main menu: first, I pick "Geometry". Next "Cylinders": default is 38828; I change it to 38827. "Heads": default is 255; I leave it. "Sectors": default is 63; I leave it. "Sector Size": default is 512; I leave it. Back to main menu.

So far this is exactly what I did last time. Now I'm diverging. Choose "Analyse". No partitions listed. "Quick Search", no to searching for partitions created under Vista, it finds the Linux LVM partition. I continue. I choose "Deeper Search". This produces:

Code:

Disk small_passport.img - 319 GB / 297 GiB - CHS 38827 255 63
     Partition               Start        End    Size in sectors
D Linux                    0   1  1 38826 254 63  623755692
D Linux LVM                0   1  1 38826 254 63  623755692

That first one is the one I want.

Now, I don't want to add a partition, load a backup, or change the type, and my only other option is list files. Just for the heck of it, I choose that one. This gives me:

Code:

No file found, filesystem seems damaged.

No surprises there. So I quit (no other good options on this screen), then enter to continue. Which gives me:

Code:

No partition found or selected for recovery

So I quit (my only option), which takes me back to the main menu. Now I'll do "Advanced". This gives me:

Code:

No partition available.

Which is where I've been stuck for several days.

Log file is attached.

Quote:

Originally Posted by unSpawn

If all fails you could opt for doing the desperate thing trying to goad fsck on by letting testdisk write a clean MBR to small_passport.img and then having testdisk delete the PT after which you could 'losetup /dev/loop3 small_passport.img; fdisk /dev/loop3;' and create a single primary partition spanning the whole disk, set it to be type 83. After that run 'kpartx -a /dev/loop3; ls -l /dev/mapper/loop*' and notice the full path for the "/dev/mapper/loop*" device. If there is such a device (lets call it "/dev/mapper/loop3p1"), then run 'mkfs.ext3 -n /dev/mapper/loop3p1' and note the line below "Superblock backups stored on blocks:". Starting with the last of these numbers run 'fsck.ext3 -dvy -b [numberhere] /dev/mapper/loop3p1 2>&1|tee /tmp/fsck.log'.

Hmmm ... sounds complex, but I'm willing to give it a try. Especially since I'm working on an image, so worst case is that I just have to reimage the drive. But it's getting late tonight, so I'll have to try that later.

Thanx for your help so far!

unSpawn · 07-06-2010, 04:42 PM

OK. Looking at your last reply and the log (thanks) I see testdisk sees a primary partition plus the LVM. I think (I'm not sure) that because of the LVM still existing it somehow won't let you choose. On top of that the LV was formatted with ext2 or ext3 so that adds more confusion (as in more backup superblocks). Destructive as it may seem I think you need to delete at least the LVM information (PV header, extents information). LVM copies the header to all disks in use, but I've also read the header is smaller on some disks. So while this may or may not be a usable approach the problem is I'm a bit rusty as to how big the header would actually be. Top of my head it should work something like this: 'losetup' the image, 'dd' the first 2 megs to a backup file, then zero out the first 2 megs. At this point you can choose to use 'testdisk' or 'fdisk'. Either way once you've created a clean MBR and restored the partition table you should run 'mkfs.ext3' with the "-n" switch just to get the "right" backup superblock locations to use with 'fsck.ext3'.

* Stupid I didn't think of this (especially since I've used the option myself before) but you could use virtualization. Using VMware (or whatever SW else you're comfortable with) you can set small_passport.img to be a read-only image and have any alteration (fdisk, fsck) not affect the original. If you're not used to using virtualization then it may add another level of complexity you can do without but if you're a quick learner, or can see the benefits, then using virtualization enables you to practice things safely and easily and by that add another level of insurance.

Xotli · 07-07-2010, 02:36 AM

Quote:

Originally Posted by unSpawn

OK. Looking at your last reply and the log (thanks) I see testdisk sees a primary partition plus the LVM. I think (I'm not sure) that because of the LVM still existing it somehow won't let you choose. On top of that the LV was formatted with ext2 or ext3 so that adds more confusion (as in more backup superblocks).

Oh, joy. :-/

Quote:

Originally Posted by unSpawn

Destructive as it may seem I think you need to delete at least the LVM information (PV header, extents information). LVM copies the header to all disks in use, but I've also read the header is smaller on some disks. So while this may or may not be a usable approach the problem is I'm a bit rusty as to how big the header would actually be. Top of my head it should work something like this: 'losetup' the image, 'dd' the first 2 megs to a backup file, then zero out the first 2 megs.

Okay, let me make sure I've got the right syntax here:

Code:

losetup /dev/loop0 small_passport.img
dd if=/dev/loop0 of=image_mbr.backup bs=512 count=4096
dd if=/dev/zero of=/dev/loop0 bs=512 count=4096

That look right?

Quote:

Originally Posted by unSpawn

At this point you can choose to use 'testdisk' or 'fdisk'. Either way once you've created a clean MBR and restored the partition table you should run 'mkfs.ext3' with the "-n" switch just to get the "right" backup superblock locations to use with 'fsck.ext3'.

Okay, so after the commands above I run testdisk again, choose "MBR Code" from the main menu, let it do its thing, then exit that, then run:

Code:

mke2fs -n

(I switched from your ext3 example to ext2 because that's what the original fs was.) Then that would give me the superblocks, right? (Then I'm not sure what I would do with those, but I trust you're going to tell me.

) I actually thought I had seen something give me those in one of the many many things I've tried thus far, but I can't recall now (and of course they may have been incorrect).

Quote:

Originally Posted by unSpawn

* Stupid I didn't think of this (especially since I've used the option myself before) but you could use virtualization. Using VMware (or whatever SW else you're comfortable with) you can set small_passport.img to be a read-only image and have any alteration (fdisk, fsck) not affect the original. If you're not used to using virtualization then it may add another level of complexity you can do without but if you're a quick learner, or can see the benefits, then using virtualization enables you to practice things safely and easily and by that add another level of insurance.

Well, at this point, I've got it imaged, and, if I muck up that image, all I lose is about 24 hours to reimage it. I might end up spending more time than that figuring out the virtualization.

unSpawn · 07-07-2010, 10:47 AM

Quote:

Originally Posted by Xotli

Okay, let me make sure I've got the right syntax (..) That look right?

Yes it does.

Quote:

Originally Posted by Xotli

Okay, so after the commands (..) run: mke2fs -n (..) Then that would give me the superblocks, right? (..)

After you run the commands to write a clean MBR and partition table you need to run 'kpartx -a' before you can run 'mke2fs -n /dev/mapper/loop0p1'. The superblock numbers you feed to 'fsck.ext2' as in 'fsck.ext3 -dvy -b [backupSuperBlockNumberHere] /dev/mapper/loop0p1 2>&1|tee /tmp/fsck.log'

Quote:

Originally Posted by Xotli

I actually thought I had seen something give me those in one of the many many things I've tried thus far, but I can't recall now (and of course they may have been incorrect).

See post #20?

Xotli · 07-07-2010, 01:37 PM

Quote:

Originally Posted by unSpawn

Yes it does.

Okay, rock on. I did all that. No issues.

Quote:

Originally Posted by unSpawn

After you run the commands to write a clean MBR and partition table ...

Oh, yeah, I forgot about the writing the partition table part. Okay, no worries. First I run testdisk /log. I use the "Geometry" menu to set the cylinders to 38827. Then I use the "MBR Code" menu to write a new MBR. No worries. Log attached.

Next, I run fdisk. I use the "extra features" menu to set the cylinders to 38827. Going back to the main menu, I use "new parition" to create a partition spanning the whole disk (default type is 83, which is right). Write that table and exit. Here's what I've got:

Code:

[root@sharn recovery]# fdisk -l small_passport.img 
You must set cylinders.
You can do this from the extra functions menu.

Disk small_passport.img: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

             Device Boot      Start         End      Blocks   Id  System
small_passport.img1               1       38827   311877846   83  Linux
Partition 1 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(38826, 254, 63)

Quote:

Originally Posted by unSpawn

... you need to run 'kpartx -a' before ...

Ah. Yet another Linunx I've never had occasion to run. Okay, one sec while I check that out ... oh, I see, it gives me a device for the actual parition in the same way that losetup gave me a device for the whole drive. Okay, so here goes:

Code:

[root@sharn recovery]# kpartx -l /dev/loop0
loop0p1 : 0 623755692 /dev/loop0 63
[root@sharn recovery]# kpartx -a /dev/loop0
[root@sharn recovery]# ll /dev/mapper/loop0p1 
brw-rw---- 1 root disk 252, 0 2010-07-07 11:22 /dev/mapper/loop0p1

That looks good, eh?

Quote:

Originally Posted by unSpawn

... you can run 'mke2fs -n /dev/mapper/loop0p1'.

Okay, let's do that:

Code:

[root@sharn recovery]# mke2fs -n /dev/mapper/loop0p1 
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19496960 inodes, 77969461 blocks
3898473 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
2380 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616

Quote:

Originally Posted by unSpawn

The superblock numbers you feed to 'fsck.ext2' as in 'fsck.ext3 -dvy -b [backupSuperBlockNumberHere] /dev/mapper/loop0p1 2>&1|tee /tmp/fsck.log'

Okay, once again let me make sure I have the syntax right:

Code:

fsck.ext2 -dvy -b 71663616 /dev/mapper/loop0p1 2>&1 | tee fsck.log

except are you sure we need the -d? The man page says it's "useless unless you are debugging e2fsck".

I'm just grabbing the last superblock backup on the grounds that, the further into the disk it is, the less likely it is to be corrupted.

Quote:

Originally Posted by unSpawn

See post #20?

Nah, that wasn't it. It was something else. But either way, we've got the numbers now, so we're good.

unSpawn · 07-08-2010, 10:32 AM

Quote:

Originally Posted by Xotli

Okay, once again let me make sure I have the syntax right

You have. In fact you did everything right and more (like setting cyls in fdisk)!

Quote:

Originally Posted by Xotli

except are you sure we need the -d? The man page says it's "useless unless you are debugging e2fsck".

I always want maximum output: easier to filter what you have.

Quote:

Originally Posted by Xotli

I'm just grabbing the last superblock backup on the grounds that, the further into the disk it is, the less likely it is to be corrupted.

We don't know where the second format put its backups so on the grounds of that I can't support the statement. In any case you should have some "old" superblocks left. I'd say let it rip! (And please post fsck.log when you've done one run.)

Xotli · 07-09-2010, 12:24 AM

Quote:

Originally Posted by unSpawn

I always want maximum output: easier to filter what you have.

Ummm ... okay. But the downside is that now it's too big to attach. I mean, the log is 3.6Mb. Even gzip'ed, that's 733Kb. Even bzip2'ed, that's 346Kb. And the attachment guide thingy says I can't attach anything over 256K. Thoughts?

Quote:

Originally Posted by unSpawn

We don't know where the second format put its backups so on the grounds of that I can't support the statement. In any case you should have some "old" superblocks left. I'd say let it rip! (And please post fsck.log when you've done one run.)

Well, I'm guessing from the size of the log that all didn't go well. I'm not sure if this was the ultimate goal, but I took a shot at mounting the partition:

Code:

[root@sharn recovery]# mount -t ext2 /dev/mapper/loop0p1 /mnt/test/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/loop0p1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So that's not good, I'm guessing.

I tried taking a look at the log myself, but it's a lot of "there was this error; fix it? yes" type lines, and a few lines with reams and reams of numbers.

Where should I go from here? Was the superblock I picked invalid, perhaps?

unSpawn · 07-11-2010, 04:46 PM

Quote:

Originally Posted by Xotli

Where should I go from here?

I need to see the log before I can make any suggestions. I gave you my drop-off email address but you didn't send anything.

Xotli · 07-11-2010, 06:47 PM

Quote:

Originally Posted by unSpawn

I need to see the log before I can make any suggestions. I gave you my drop-off email address but you didn't send anything.

Sorry! Real life was kicking my ass there for a while.

It's been sent now. Apologize for the delay.

unSpawn · 07-12-2010, 05:44 PM

Quote:

Originally Posted by Xotli

Well, I'm guessing from the size of the log that all didn't go well. I'm not sure if this was the ultimate goal, but I took a shot at mounting the partition: (..) So that's not good, I'm guessing.

Sure mounting the crippled file system was worth a shot but 'disktype /dev/mapper/loop0p1', 'tune2fs -l /dev/mapper/loop0p1' and 'dumpe2fs /dev/mapper/loop0p1' could have given you more information without mounting. (What's their output anyway?)

Quote:

Originally Posted by Xotli

I tried taking a look at the log myself, (..) lines with reams and reams of numbers. Where should I go from here? Was the superblock I picked invalid, perhaps?

The log you sent me (thanks) shows fsck connected a lot of files to lost+found. That may be good, annoying, bad or catastrophic. Let's see. Take one of your superblock numbers from your earlier 'mkfs.ext2 -n' output (try three in total but not consecutive ones) and run 'debugfs -b 4096 -s [SUPERBLOCK_NR] /dev/mapper/loop0p1'. Now you can 'ls' and 'ls -l lost+found'. You can even try 'lsdel' or try to 'imap' an inode because since you run without "-w" there's no chance of modifying the file system anyway. Feel free to experiment a bit. If 'debugfs' is not your tool try 'testdisk /debug /log /dev/mapper/loop0p1'. Now Proceed > None > Advanced > Superblock. See if that list is similar to your earlier 'mkfs.ext2 -n' output. (Superblock numbers that aren't in 'mkfs' output I'd avoid.) Now Quit > Analyze > Quick Search > P. Now you can "walk" the filesystem. Let us know if it shows anything or errors. If none of this shows anything (please check your logs for clues) you could try running 'photorec' on the partition in a last ditch effort.