WD My Passport Edge disk very slow access - recovery
There are two kinds of people. Those who backup, and those who hadn't lost
their data yet.
--Shaddack
I was asked to recover data from an external hard drive My Passport Edge
(500GB - p/n WDBJBH5000ABK-03).
The software recovery took more than one year on a dedicated laptop.
Disk was stuck upon plugin-in, able to read some data at 30kB/s (not enough
for even mounting) after and then slowed down to speeds like 1024 b/s.
Restart would help for some time.
After opening the casing of drive, found that there is no sata connector on
drive itself, just some proprietary exotic USB. Some youtube tutorials
offered the possibility of soldering-on the sata interface, since I'm not
much into hardware, I was trying to find software solution.
// https://www.youtube.com/watch?v=NsnS6N9veFg
Stage 1 - Mac
* Found amazing CLI tool ddrescue. First used under MacOS X and done 'first
pass'.
// https://www.gnu.org/software/ddrescue/
* I used sequence -- connect drive, wait few seconds until system recognises
it -- unload disk arbitrary daemon to stop the system mess with drive (fsck,
try to mount etc.) -- run ddrescue (script with command line). When the data
stoped to come, restarted the computer.
#unload diskarbitration daemon
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist
#get the data
ddrescue -vv -P -D /dev/rdisk2 mydrive-backup-image.img ddrescue.log
#eventually load the daemon again
sudo launchctl load /System/Library/LaunchDaemons/com.apple.diskarbitrationd.plist
* I used faster direct device /dev/rdisk2 instead of default /dev/disk2.
# with another failing drive, infamous seagate barracuda 3TB, careful
# fiddling with cluster size option and evaluating the average read graph,
# was beneficial ( -c 8128 or 4096 or even 6144 )
Since MacOS X kernel had quite long delays/timeouts accessing unreadable
drive (timeouts in syslog) and trimming phase droped to some 1024 b/s, decided
to try Linux.
Stage 2 - Linux
* I used discarded laptop with broken screen and keyboard, with electricity
consumption as low as 2 watts. No excessive computing power is necessary and
low-comsumption was a virtue in such a long continuous run.
* Did the first-pass again on Linux and merged the data from Mac and Linux
experiments.
* Linux coped with the corrupted drive much better. I installed monitoring
tool Munin, to find some performance pattern (diskstats_latency). Drive
read 16 / 20 kB/s after reboot, with two or three short peaks of 300kB/s
(personally called 'golden rain') in two hours period. After two
hours and approx 100 MB of data, dropped to 2 kB/s for good. Disk sound was
different for all those phases. Restart helped. Ran this sequence for
quite long time.
ddrescue -vv -D /dev/sdb ./mydrive-backup-merged.img ./ddrescue-merged.log
Diskstats_latency of Munin - period of 2.5s average latency is ended
with reconnecting the drive, then the drive works for 2 hours
* Direct mode (-d) didn't give better speeds.
* Tired of continuous restarting the laptop, found that it's enought to
physically disconnect the drive and connect it again after few seconds. It
was more than one year since start of recovery.
* Didn't find any solution how to automatise the disconnect/connect
sequence.
* Missing the nice 'data preview' feature (ddrescue v1.21 from MacOS
macports) in ddrescue in Ubuntu (v 1.14), compiled version v1.21 out of the
sources. 'Golden rain miracle' increased to super-sonic speed of 1.8MB/s!
Almost physical relief!
/usr/local/bin/ddrescue -vv -P18 -D /dev/sdb ./mydrive-backup-merged.img ./ddrescue-merged.log
* Three days after, trimming phase was completed. 50% recovered. Further
scraping didn't get any more data for next three days, attempt finished
with 250GB of recovered data.
Conclusions
* Use low-consumption computer
* Use linux
* Use latest version of ddrescue
* Data recovery companies are NOT too expensive
* Do the backups. Do the backups. Do the backups.
EOF
Comments requested
~~~~~~~~~
Binary Sxizophreny - index of comp related stuff
Kangaroo's Homepage (czech)