Hi there,
I'm trying to rescue some data important to me from a broken WD 500GB drive. I guess PCB is broken, as the drive reports SMART okay.

What I'm trying to do is rescuing a few very small files from an ext4 linux fs, and my problem is, the drive doesn't read any blocks longer than 128kByte, after that it usually freezes BUSY. However it seems, it DOES give me correct data on any first drive access after a power cycle on the drive.

I'm using MHDD to get access to the data. What I'm trying to do is to extract just the sectors I need to access my little files, using MHDD, copying just the superblock, the directories needed, and so on, and using them in a loopfile later.

Is there a way to use "TOF" in MHDD in scripts? How do I pass filename, start LBA and end LBA from my script? Manually typing start and end sector is very time consuming and worse, it's easy to do some errors.
As I generate the list of sectors needed in an semi-automated way, it would be great to be able to write the sectors to an SCRIPT.MBA instead.

Has anyone has a better idea how to get data from the drive?

You likely need, at the very least, a new PCB with the ROM transferred. These drives can also have head issues as well. If your data is important, seek the assistance of a pro with all the necessary tools to get your data back without taking any risks.

_________________
Luke
Recovery Force Data Recovery

yeah, however as I can't afford a pro, I have to try on my own.
actually the method works, and as I only need 2 small files of all the data lost, I would like to try it with the partly broken PCB

each time I request a block of 256 sectors only the drive gives me that sectors (128kB) before failing. the problem is, when I type the LBA numbers manually, I might mistype somewhere without notice. so I wondered if it was possible to feed that numbers in a semi-automated way, like generating a script to run

@nicolai:

I've never seen MHDD TOF used in that way, from an "external" script.

You could consider using dd(rescue) under Linux, which can definitely be scripted, if you are accepting the risks of DIY.

unfortunately I _have_ to accept that risk. no money, no pro. hopefully some luck.

however the linux systems I've found, all keep the drive too busy during boot up, all end up with the device not seen anymore once I get a shell. Haven't tried with a static /dev and without udev yet, might be worth trying.

But since MHDD is a lot more successful than anything else I tried, and it actually is scriptable, I thought it is probably just about the syntax.
The documentation of MHDD however doesn't tell anything about TOF in scripts, surprisingly enough.

This can be caused by the filesystem automounting during boot with a failing drive, due to all the disk accesses which automounting can trigger. You may want to investigate disabling that - some LiveCD / USB distros have automounting disabled by default.

You could connect to Linux via USB controller, too.

_________________
Luke
Recovery Force Data Recovery

@lcoughey:

Agreed Luke - however I deliberately didn't recommend that due to the previous examples on here, where people reported better results with the faulty drive attached via (S)ATA compared to USB, due to the lack of direct control of what the USB bridge actually sends to the drive. For this reason I wouldn't do it, but as you say, the OP could consider this.

I know where you are coming from, but in the case where the drive goes offline before Linux boots, it is just a suggestion...as they won't be sending any special commands within Linux anyway. For MHDD, he would definitely not want to use the USB enclosure, but either way, he has a huge battle of time ahead of him for something that would likely take any professional lab a few minutes to do, assuming that they have the correct PCB in stock and the heads are healthy on the original.

_________________
Luke
Recovery Force Data Recovery

I already tried connecting via USB, but the device disconnects within 1 second after it becomes visible in linux, it probably depends on the usb-adapter, too, I only had a single adapter to test with (Logilink)

Does this happen even with automount disabled? It could still happen (I've seen it before), but it's worth checking, if you have not done this already.


Yes it could vary, because the adapters implement their own timeout & error recovery algorithms, so they can choose to take their own decision about when the external device isn't behaving normally, not just the OS.