[mythtv-users] Consequences of drive failure
tortise
tortise at paradise.net.nz
Wed Dec 5 08:33:55 UTC 2012
On 5/12/2012 8:29 a.m., Nick Rout wrote:
>
>
> On Wed, Dec 5, 2012 at 8:27 AM, Nick Rout <nick.rout at gmail.com
> <mailto:nick.rout at gmail.com>> wrote:
>
>
>
> On Wed, Dec 5, 2012 at 3:11 AM, Mike Perkins
> <mikep at randomtraveller.org.uk <mailto: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
>
As I'd filled my four SATA ports I added a
http://www.sunix.com.tw/product/sata1414.html for its speed and still
not too expensive. SATAIII's are also available, and possibly not that
much more....
More information about the mythtv-users
mailing list