auto-rebuild RAID mirrors

[Bill McGonigle]

On Apr 18, 2007, at 10:35, Thomas Charron wrote:

>  Hrm, apperently, this is all gone in 2.6, sorry for pointing the
> wrong way.

No problem.  I'll see if I can find some discussion about its  
progress and removal, that may be enlightening.

>   The entire md.c was split up into it's own directory.  I
> wonder if there is a way to permanently attach a given drive to a RAID
> array, so it remains there if it's present or not.

I've found I have to --fail and --remove a drive to get it out  
cleanly, so my guess is 'no', but many mdadm tricks seem to be  
lightly documented, so I'd love to learn there was another way.   
Dedicated RAID hardware often allows marking of a RAID-1 drive as not  
participating, so this task is a matter of pulling a hotplug slot and  
replacing it.  UUID's or whatever they use just do the right thing  
automagically, but like you say it still has the concept of that  
drive participating, even if it's 'failed'.  Pre-2.6 I tried just  
marking drives 'failed' and pulling the hardware but _bad things_  
happened when I did that.  I haven't yet had the temerity to try that
on 2.6, but I will do that when I get another pair of 320MB drives in  
from NewEgg ($75!) in the next couple weeks (so I have two sets  
offsite, for better disaster recovery odds).

>   You're right, I'm
> suprised there isn't more on this online.  It's a GREAT idea to mirror
> a local drive over an external mass storage drive.

It's worth noting that I only usually achieve about a real 14MB/s on  
the USB drives.  Firewire gets about 24MB/s, but I had to pull that  
card when I got a new mobo to fit an e.SATA card in (fewer slots).   
Either way, there's a big write performance hit, so I wouldn't do USB  
for mirroring a main drive.  In this case, I have 4 drives for  
backup, two as the permanent members, two as removable.  That way I  
can just rsnapshot the main drives to the backup pair (RAID-0)  
overnight and then pull 1 RAID-1 member of each backup pair for off- 
site storage.

The e.SATA drives should be much better, speed wise, when I get the  
latest kernel installed (for chipset support), so the above problem  
shouldn't exist for e.SATA, but there still is the problem of having  
only 2 ports on an e.SATA card while my mobo has 4 USB ports and 4  
more stubbed out on the mobo as headers.  I got a pair of these:

   http://cwc-group.com/duusbfeto2xi.html

to stub out four more USB connections to handle the backup set. Very  
handy since my case had two more expansion slot openings than my new  
mobo had.

I could mirror my main backup drives over e.SATA, but in this case  
this machine is handling backup for several servers (via rsnapshot),  
so while I could just partition off enough space to do a 3- (or 4!)- 
way mirror of my main drives, the versioning that rsnapshot gives me  
is worth the trade-off.   The e.SATA ports are marked for holding my  
mythbackend data.

It's also worth noting that ZFS does all of this automatically  
already, including the snapshots (instantly), so I'll probably try  
moving the whole backup system to ZFS when I get another machine for  
a Nexenta (Ubuntu on an OpenSolaris kernel) box.

-Bill

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
New Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf