|
From: | Iphone Recovery Online Info |
Subject: | Re: [Bug-ddrescue] ddrescue produces 0 bytes output |
Date: | Sun, 31 Mar 2013 10:50:02 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
Hi guys,
If I may share my experience: many times when I receive USB-connected hard drives for recovery, the only thing I need to do is just to remove the hard disk from the USB enclosure, and connect it directly to SATA, and have the disk working fine immediately. This led me think that this - often low-quality - SATA-to-USB bridge is just one more thing to fail in the chain. Thus I always start with removing it. In other cases, via the USB bridge, the HDD seemed to be almost completely unreadable, while via SATA it turned out that it just had minor read errors.Don't *ever* try to do a drive recovery through a USB bridge: pull the drive out of the housing and hook it directly to a SATA port. You can't trust a random USB bridge chip to have enough commands to do everything you need to do during a recovery.What sort of commands? To date I've not had any problems with USB2 or USB3 external docking units. I have found no troubles that I'm acutely aware of with powered USB external-drive enclosures either (Seagate); sometimes I have had hiccups with 2.5" non-powered bridges, but that's somewhat to be expected due to the limited power, especially if the drive has a motor issue. Overall I have found recovery via USB-bridges to be more dependable than eSATA or SATA directly, particularly if the drive resets frequently. Though it's likely a kernel/driver issue I have found that when directly connected to the SATA interface I often have the drive become completely no-responsive to the system ( but reestablishes fine if you reboot ).I am quoting others; I have never done a recovery attempt through a USB bridge, based on their recommendations. Alas, I'd have to go dig you up references; I often store only the integrated result, rather than the source material, in my head.
Never did the opposite, though (connecting a SATA bridge to a SATA drive to do recovery). I cannot see a reason why such an extra layer could make things better? During everyday use (non-failing drives), I find USB drives consistently slower than direct SATA drives. Others have similar experiences (please note this is USB3):
http://www.anandtech.com/show/6014/startechcom-usb-30-to-sata-ide-hdd-docking-station-review/3Anyway, just my 2 cents. Everybody will continue doing it the way they found better in the past, I guess ;)
As of Rogerio's original question:
I have had an external HD failure and all my family pictures are there. Yes, I know that I'm a big beast ... If you can believe ... there are no backups.As suggested above: first thing is to remove it from the USB enclosure and try it via SATA. If this does not help: could you please let us know if it makes any unusual sound during startup, during the few seconds while you can read, or when it goes "offline"? Also, if you could run MHDD on it, scanning at least at the beginning, the middle and at the end and let us know the results, that'd help.After the event, I tryed ddrescue but it doesn't read the disk. errsize: increases, rescued: remain zero and output is also zero.I have notice that when the external HD is plugged in, it is recognized by Linux for a few seconds (~30 seconds), and during this time ddrescue can read it content. After that few seconds, it seems that the operating system filters out the disk and it becomes invisible to ddrescue, fdisk and also dd.
You wrote that during the first 30 seconds, ddrescue can read it. But you also wrote that rescued data always remains zero. How can that be? If your hard drive is indeed reading with full speed during the time it's operational, you may consider using a tool that restarts it automatically when it goes offline, like this one:
http://www.copyrsoft.com/index.php?option=com_content&view=article&id=51%3A--hddup-power-controller&catid=34%3A2008-10-26-06-17-45&Itemid=59&lang=en Best regards, Peter
[Prev in Thread] | Current Thread | [Next in Thread] |