Bonjour a tous

Some months ago I replaced the 360G by 1T and I was happy, very happy until a bad day when my laptop did'nt went to sleep properly and was transported on a bike with the disk spinning. After that it did'nt boot any more of course. Few unvaluable data were added during these months fortunately. Nevertheless I tried to recover something.

I put the disk in an external USB enclosure.
First attempt on the laptop whith the previous disk (ubuntu 10.04 and linux3.0). The disc is recognized with read errors and the raw device /dev/sdb is not created and disapears.

Second attempt on an older system (ubuntu 8.04 and linux 2.6.12). I'am able to copy data from the damaged disk on another 1T disk with dd ddrescue and safecopy. Usualy the copy stops without any message after few dozen of G.


Then I use gpart to find the starting points of the partitions.

The next step is to use a loop device on the backup disk with offset to mount the partition on the system.

It should work but is not working as it should


Does somehome has experienced that problems?

Alex

You can find related threads at the bottom, try testdisk.

testdisk fails since it access the MBR and open is blocking

Mount requires a valid filesystem. If the damaged area includes the first couple of cylinders (likely if the MBR is lost), then you have also lost the beginning of the filesystem for the first partition at least. Hence the inability to mount that. Other partitions may (or may not) loop-mount successfully depending on luck.

Of course since the beginning of the disk is damaged, there is no hope to recover the first partition wich hosts the system, The system is perfectly standart and is completely separated from my data.

I found at least one partition on the partial copy made by dd and skipping bad cylinders. I'm able to inspect the loop device created with the proper offset with debugfs and to mount it on a linux-3.0.

I modified gpart to prevent it to try to read the MBR what was hanging the process, and start running it on the whole disk skipping the begining. It last quite a while.

I need then just to find out how to prevent my linux-3 or ubuntu to remove the raw device if it is not able to read the MBR when I plug the USB-SATA adapter..

Any stderr, diagnostic output, dmesg and syslog output from the moment you powered up and tried to access the USB enclosure would have been welcome.


See dd_rescue instead as I explained here?


Instead use 'testdisk' with the "/debug /log" flags and store the log file somewhere safe.


No, the next step should have been ensuring a copy of the disk was made to file and work on that. Besides please don't talk about errors ("is not working") but show them instead (stderr, diagnostic tool output, dmesg, syslog).


There are several options open to you. For instance testdisk allows you to write a standard MBR and if testdisk can recover partition boundaries after that it may well be able to rewrite the PT as well. I strongly suggest you first make a good copy of the disk or partition though. And if the first partition of the disk only contains the system and the subsequent partitions data to retrieve, why not image only those?

As I wrote previously my problem is solved and I got my data back with the following procedure.

Instead of copying all the recoverable sectors from the damaged disk on a new disk:
I modified gpart to prevent it to access the mbr
whith this modified gpart I was able to detect the begining off all my partitions but the first which hosted only a plain system
I used loop devices with offsets to mount the detected file-systems (the mount failed at the begining because some of my file-systems where ext4 and the old system I used did'nt support ext4)
I selectively rsynced the modifications to the original disk (which was copied and expanded to the 1Tb disk)

From all the tests I did, it appears to me that
dd whith conv=noerror,sync skip=xxx seek=xxx is not worse than ddrescue
safecopy is also a usefull tool
testdisk works only on a disk without errors (after a full copy)

Any media error (read error on disk) takes several seconds to recover.
If they were kernel parameters preventing multiple retries and offlining the device with errors, data recovery could be much more effective.

Alex