[lug] upgrading OS on RAID1

[Lori Reed]

I did this as a matter of routine when I was the system architect for a 
voice mail/voice processing system. However, the system I designed used 
an external scsi raid 1 controller, so it was mostly invisible to the
o/s at runtime and completely invisible to the bios at boot time.

I presently have 2 mobos with on-board ide raid 1 controllers, but I've 
never used this feature so I don't know how the bios responds at boot 
time. Since both of these boards also support booting from drive D, I 
presume the right thing will happen if either the primary or secondary 
drive is absent at boot.

One thing that worked so well in my raid 1 days that I still do it today 
is to put all hard drives in removable carriers.

IMNSHO, software raid is seldom, if ever, a good idea.

Lori

durist at frii.com wrote:
> I've just ordered a second IDE hard drive for my home machine (AMD/Debian) 
> which I'm planning to use as an OS mirror. Aside from adding hardware 
> redundancy, I wanted to do this so I could break the mirror, upgrade one side 
> and test it, and then revert to the other mirror if something goes wrong 
> (especially since my wife uses this machine for work and she's currently 
> paying the bills). This has become more or less standard operating procedure 
> for Sun/Solaris production systems, and it's made relatively easy by putting 
> in device aliases for the boot devices in the Sun's NVRAM. This sadly is a 
> feature that Intel boxen don't have. I was curious if other people routinely 
> do this split-mirror/upgrade/test/sync-mirror procedure on intel, and what 
> pitfalls there might be (other than the obvious dangerous confusion over 
> which disk is which at 3am-- in my Solaris experience this is the sort of 
> procedure you want an explicit checklist for). I've googled around, and I 
> haven't seen any mention of this as one of the advantages of doing software 
> RAID 1 on linux, which seems odd.