[mythtv-users] Lost Drive!

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Tue Aug 26 08:58:12 UTC 2008


I'd try cloning the drive to a new one.  The old one sounds like it
has hardware problems, but it may be possible to rescue it, perhaps
losing a sector or two (which might toast a single recording, but not
your whole filesystem unless you're really unlucky).  I've done this
half a dozen times on a series of horrible Maxtor drives that all died
with a click-of-death; it worked every time.  (And then I swore off
Maxtors forever, since the "bad batch" seemed to be a couple of years
long, spanning at least 6 replacement drives for only two originals!)

Assuming that /dev/hda is the clicking (old) drive, and that /dev/hdb
is some new drive (at least as large as the old one), do this:

  dd if=/dev/hda of=/dev/hdb bs=1M conv=noerror,sync

[This command line is UNTESTED, so verify that I didn't typo it.]

Be absolutely sure you do not get the devices swapped around!
If you overwrite the first few meg of your bad drive with the
new drive, you're toast.  [If the new drive is actually -brand- new,
it's usually full of zeroes, so one way I verify that I didn't somehow
get my cabling/jumpering confused is to do "strings /dev/hda" and
"strings /dev/hdb" as root---the new one won't print anything even if
you wait a few seconds, but the old one will blat out all kinds of
strings from various partitioning & filesystem stuff, etc.  Crude
but effective.  Just ^C it when you start seeing text appear.]

Once you've done this, -don't- reboot, because LVM will complain that
you have two drives with the same UUID.  Instead, shut down the
machine.  Yank the bad drive, then power back up.  Everything should
be fine.

This is brute-force, but it also touches the bad drive as little as
possible and doesn't write to it at all, which increases the chances
you'll get good data off of it.  If possible, do this with the
filesystem on that drive dismounted; if you can't do that and still
have a functional system, you can at least try to ensure nothing is
writing to that filesystem.  (Or you can boot from a LiveCD, etc.)

If dd can't even finish reading the drive (e.g., just clicks forever
and doesn't make progress), I believe there are adaptive dd-like tools
that can attempt somewhat more-intelligent recovery.  (Or you can do
it by hand with creative use of skip= and seek= to dd and multiple
runs to recover subsections of the drive.)

Also, you may be able to minimize zeroed-out holes in the destination
(where dd ran into an unreadable sector and substituted zeros) by
using bs=512 instead of bs=1M; it will run far slower, but it will
read each sector individually instead of lumping lots of (probably
unaffected) sectors in with a sector that's causing the drive issues.
If you're careful with the math, you can read most of the drive with
a large blocksize and then use tiny little reads on the part(s) of the
drive that err; this will require keeping your arithmetic right when
giving args to bs, skip, and seek.

[All of this assumes that it's only a few isolated spots on the disk
that can't be read.  If the clicking is because the head can't read
the disk at all---which I doubt since then you wouldn't be talking
about trying to recover your data---then you're toast and will have
to tell LVM to forceably remove the PV---which will also trash the
filesystem in the rest of that LV, so I don't recommend it.)


More information about the mythtv-users mailing list