BackupPC-users

Re: [BackupPC-users] Optimizing backupPC

2008-05-05 14:00:09
Subject: Re: [BackupPC-users] Optimizing backupPC
From: Les Mikesell <lesmikesell AT gmail DOT com>
To: Carl Wilhelm Soderstrom <chrome AT real-time DOT com>
Date: Mon, 05 May 2008 13:00:19 -0500
Carl Wilhelm Soderstrom wrote:
> (NB: Les and I have gone back and forth on this issue before, and I don't
> sense any hostility involved; we just have different experiences and
> requirements, so we disagree firmly but politely).

Yes, I have nothing in particular against hardware raid, but like the 
simplicity of software mirroring and the advantage of being able to 
recover the data from any single drive.

>>> That said; my experince with software RAID is that if one of the disks dies,
>>> the whole machine might fall over anyway. In most cases you have to down the
>>> box and reboot in order to swap in a new drive.
>> That's typically related to IDE (PATA) hardware, not anything to do with 
>> RAID.  SCA (swappable scsi) or SATA in a swappable tray wouldn't have 
>> those issues.
> 
> I can't say I have firsthand experience that way; can you enlighten me how
> it is that PATA failing can cause the OS to crash, but not SCA/SATA?

It isn't the OS.  The drives typically fail in a way that locks the 
controller/motherboard especially when booting.  It is hard to simulate 
or test because removing the drive doesn't cause this.   With scsi, 
access will time out and move on to the next choice when booting.  I 
haven't actually had a boot drive failure with SATA so I'm not sure how 
gracefully they handle it - but with swappable trays you could always 
yank the hanging drive anyway.

>>  > Also, if you're using this
>>> array as your boot drive; it's easy to screw up or otherwise fail to have a
>>> bootable drive, when the first drive dies.
>> Worst-case is that you boot a CD in rescue mode and reinstall grub 
>> (there's only 2 choices, depending on how the system sees the 2nd drive 
>> when the first fails...).  And you should know how to do that in any 
>> case since other things can go wrong.
> 
> Yes, it's good to know how to do that.
> That said; it's at least 15 minutes of work under ideal circumstances; and
> can easily run to an hour if things don't work quite right the first
> time and/or you don't have the information on how to do it off the top of
> your head.

But this is consistent regardless of the actual controller involved. 
With hardware raid, you'll have to track down different vendor's 
instructions, and perhaps current drivers, separately for each type.

> (Firewall is the machine you're trying to fix, so you can't
> access the Net to look up the syntax, you can't find the documentation
> on the machine itself because it's a minimal install, the customer is
> hovering over your shoulder asking when it will be done and what's going
> on... 

A wireless card in your laptop can take care of that sort of thing.

> these are just the first things that occur to me that I've seen while
> trying to fix software RAID). Based on my real-world experience I allocat at
> least an hour to fix a software RAID array with a bad disk;

If the machine is still running, you just fdisk some matching partitions 
and mdadm --add time back in.

 > whereas swapping
> a disk in a 3ware controller shouldn't take longer than 10-15 minutes. That
> time differential pays for the cost of the controller (2 port controller,
> YMMV).

And if I were doing it, I'd expect to spend half a day on the 3ware site 
looking for the instructions.

> I'd prefer to leave the complexity on the machine rather than require a
> human to do the tending of that complexity. Humans are much more prone to
> making mistakes.

Mdadm is pretty good about warning you if you try something stupid. 
Fdisk, not so much - but you have to deal with it sometimes anyway.

>> That's a problem with consultants...  The plus side of software raid is 
>> that there are no other dependencies.  If you have nothing left but one 
>> drive (assuming raid1) you can plug it into just about any 
>> hardware-compatible controller or even a cheap USB adapter and access 
>> the data.  With hardware controllers you'd probably need to keep 
>> matching spares on hand.
> 
> This is a good point; but I've never found it to be a problem in the real
> world.

I start with the premise that I want to be able to restore from a 
mirrored copy of my backuppc archive.  It hasn't actually been necessary 
but I still consider it a big plus that in a disaster recovery scenario 
I can plug this copy into a laptop and restore files instantly.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/