[mythtv-users] Consequences of drive failure

Nick Rout nick.rout at gmail.com
Tue Dec 4 19:29:24 UTC 2012


On Wed, Dec 5, 2012 at 8:27 AM, Nick Rout <nick.rout at gmail.com> wrote:

>
>
> On Wed, Dec 5, 2012 at 3:11 AM, Mike Perkins <mikep at randomtraveller.org.uk
> > wrote:
>
>> On 03/12/12 21:14, Michael Watson wrote:
>>
>>> On 3/12/2012 7:19 PM, Simon Hobson wrote:
>>>
>>>>
>>>> As to copying your drive, my technique is this :
>>>> Install the new drive in the system along side the existing one - you
>>>> can now
>>>> let the system continue running as normal.
>>>> Partition & format as required, mount somewhere on the filesystem. Use
>>>> rsync
>>>> to copy the recordings from the old drive to the new one. You can do
>>>> this in
>>>> batches if you want, stopping before the backed has to do any Myth
>>>> related
>>>> work (eg recording or serving up frontends).
>>>> When ready to make the switch, stop the backend, run the rsync copy
>>>> again to
>>>> get the replacement drive fully up to date, make any changes that might
>>>> be
>>>> needed to fstab etc, shutdown, remove the old drive and start up.
>>>>
>>>>  I would add the new drive, create filesystem and mount, add the new
>>> drive to the
>>> default storage group, and remove faulty drive from the storage group,
>>> so no new
>>> recordings will be written to the old drive, (but you will not be able
>>> to access
>>> the recordings on the old drive from within myth unless you create a new
>>> storage
>>> group with the old drive included).
>>>      Copy the recordings over using rsync, but precede the rsync command
>>> with
>>> "ionice -c3", and let the copy run its course.  Once done, modify fstab
>>> to
>>> include new drive and remove the old drive, shutdown and physically
>>> remove old
>>> drive.
>>>      Power up, run find_orphans.py to clean up any missing recordings.
>>>
>>>  So, what is going to happen when your rsync operation meets the first
>> defective sector?
>>
>> As it happens I have no intention of attempting any of this with the
>> existing server host, (i) I would expose the other drives to potential
>> operator error (ii) there are no free SATA slots which means more potential
>> error juggling drives around (iii) every time I boot the server mythbackend
>> will start and try to do things to the disks.
>>
>> There is a minor issue I have: the two old drives have the same geometry,
>> the two new drives do as well, but the old drives have 512-byte sectors,
>> the new ones have 4096-byte sectors. My plan is this:
>>
>> Remove good old drive, mount with new drive in spare host. Rsync files
>> across. Put new drive into MBE slot where good drive was. (Er, fix fstab
>> for new UUIID.)
>>
>> Remove bad old drive, mount into spare host alongside good old drive
>> (same geometry). Use dd_rescue to bit-copy from bad to good. When happy
>> with result remove bad old drive.
>>
>> Put remaining new drive in spare host, rsync from good old drive to new
>> drive. Remove new drive and put into MBE.
>>
>> ??? Profit!
>>
>>
> Sounds like it will work, but it will be MUCH faster if you can use a sata
> port on your motherboard, or even get one of those usb to sata connectors
> and plug it in the back.
>

Like this is what I mean: http://jaycar.co.nz/productView.asp?ID=XC4833



> I took my backend offline while doing it, and simply temporarily
> decommissioned one drive that wasn't involved in / or the faulty drive,
> juggling the others as needed.
>
> As you say UUID is the way to go :)
>
>
>
>> --
>>
>> Mike Perkins
>>
>>
>> ______________________________**_________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121205/ef5c83d5/attachment.html>


More information about the mythtv-users mailing list