[mythtv-users] Reviving a myth system after hardware failure on /var

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Nov 5 14:09:56 UTC 2014


On Tue, 4 Nov 2014 23:54:08 +0000, you wrote:

><https://forum.mythtv.org>
>
>>  I might partition the new drive the same (or similarly) as the old drive,
>> and format each partition as desired.  I would then use rsync to transfer
>> the data from each partition (file system) from the old drive to the new
>> drive.  I would then try to repair any known broken files on the new
>> drive.  You might need to adjust UUID values for the drive/partitions for
>> mounting.  I tend to prefer rsync over dd, because it only copies the parts
>> of the disk that have actual data and it does respect bad blocks on the new
>> drive that partitioning/formatting might find and mark.
>>
>
>If I use rsync instead of dd or dd_rescue, how do I make the new drive
>bootable? The MBR will be wrong. I guess after copying the files I'll have
>to boot cautiously from the old drive BUT mounting the right partitions on
>the new drive and then do some kind of grub-install...
>
>Anyway, after all that, and after repairing broken files (if it works),
>would you leave it at that or would you try to restore a db backup?

I have recovered a drive like that (with only a few bad blocks in one
partition) at least twice now that I can remember.  What I did was to
use gparted to copy all the unaffected partitions from the bad drive
to the new good one, which is a relatively fast job.  Then I used Gnu
DDRescue (ddrescue, not dd_rescue which is a different program that
does not work as well) to copy the bad partition file by file.  That
took longer, but most of the files copied quickly, leaving just a few
with bad blocks that took a while.  I had ddrescue do lots of retries
on the bad files, and in my case it eventually (after hours of
trying), got what it thought was good copies of all but one file the
first time, and all files the second time.  My affected partition in
each case was a JFS recording partition though - so my bad files just
wound up with a glitch when played and were all watchable.

Your problem with the program.MYI file is not too bad either if that
is the only affected file.  A .MYI file is just an index and I believe
it can be recreated from the main program.MYD data file with the
proper mysql commands, although I have never done that.  And in any
case, the I believe that the program table is just the EPG data and
can therefore be recreated in its entirety by dropping the table and
creating a new one, then using mythfilldatabase to reload all the
current EPG data.

Making a Linux drive or partition bootable again after copying like
that depends on what distribution you are using.  All Ubuntu based
distros can fix a drive to be bootable again by booting from the
installation disk (live DVD or live DVD image on USB stick) and
(re)installing grub2 to the hard drive.  The web has instructions on
how, and I have had to do that a couple of times too with Mythbuntu
and it worked fine.  But it is a fiddly, detailed process you have to
go through.  Read ALL the instructions carefully!  I missed a step the
first time.  You also need to check the /etc/fstab setup as the UUIDs
are going to have changed on the new drive.  I usually use partition
labels now instead of UUIDs to avoid that problem.  Again, you can
edit fstab using a live CD/DVD boot.  If your favourite editor is not
available on the live DVD, then you can just use apt-get to install it
temporarily in the RAM image the live DVD is running out of.  Of
course, you have to do that again every time you reboot the live DVD.

Having a bootable image on a USB 3 stick is one of the essential tools
I try never to be without.  On systems that can be booted from USB 3,
it is much faster that using a live DVD.

Here is an example of a script I wrote to recover a recordings
partition from a bad drive to a good one:

#!/bin/bash

cd /mnt/old/recordings
for a in * ; do
    ddrescue -v /mnt/old/recordings/$a /mnt/new/recordings/$a
/mnt/rescue/$a.log
done

(Watch out for line wrapping - the ddrescue line is all one line and
is long enough that it will likely show up as two)

The script assumes that the old partition is mounted on /mnt/old and
the new partition on /mnt/new.  Once the script completes, you need to
check all the log files in /mnt/rescue and find any files that did not
copy properly.  You can then use ddrescue on those files with
different options to make it try much harder to read the bad files, if
you want to spend the time (hours or days) doing that.

In your case, you would need to use a tool that provided the for loop
with a full directory tree of the partition you are recovering, so the
script would have to be a bit more complicated.  The command "find /"
would probably be what you need.


More information about the mythtv-users mailing list