If I were to have a server running RAID 1 and my controller were to
die, could I plug in one of the drivers from the array directly into a
controller and run the server?
Obviously you couldn't do this with RAID 0 or 5, but I am assuming
that I could do this with RAID 1.
On Mon, 15 Oct 2007 15:42:15 -0700, cmay
<cmay@walshgroup.com> wrote:
>If I were to have a server running RAID 1 and my controller were to
>die, could I plug in one of the drivers from the array directly into a
>controller and run the server?
Yes, if the drive were usable as as single non-raid volume
direct from the other controller, it should be readable as
one of the two members of the raid array with all the data,
BUT if you want to use it as a RAID1 array with the other
member on a different raid controller, you may need to
rebuilt the array from one member to the other (which is not
a problem, just something to be aware of).
>
>Obviously you couldn't do this with RAID 0 or 5, but I am assuming
>that I could do this with RAID 1.
Yes, though it is far less likely a controller would die
than a motherboard or hard drive.
cmay wrote:
> If I were to have a server running RAID 1 and my controller were to
> die, could I plug in one of the drivers from the array directly into a
> controller and run the server?
>
> Obviously you couldn't do this with RAID 0 or 5, but I am assuming
> that I could do this with RAID 1.
>
Why not test the theory now, while there is no data of value on
the array ? Portability is not a given with RAID arrays. Neither
is RAID1 a replacement for backups. If you have daily backups
(full + incrementals), you don't have anything to worry about
anyway. A simple restore, will fix you up again.
Paul wrote:
> cmay wrote:
>> If I were to have a server running RAID 1 and my controller were to
>> die, could I plug in one of the drivers from the array directly into a
>> controller and run the server?
>>
>> Obviously you couldn't do this with RAID 0 or 5, but I am assuming
>> that I could do this with RAID 1.
>>
>
> Why not test the theory now, while there is no data of value on
> the array ? Portability is not a given with RAID arrays. Neither
> is RAID1 a replacement for backups. If you have daily backups
> (full + incrementals), you don't have anything to worry about
> anyway. A simple restore, will fix you up again.
>
> Paul
Also, I'm required to add to this, that information about the
RAID array, is stored on the disk(s) themselves. The motherboard
does not have any essential information stored in it, about the
array. If the motherboard dies, and an exact replacement motherboard
is provided, the RAID will pick up right where it left off.
For example, say I have an Asus motherboard with a SIL3112 RAID
chip on it. I prepare a RAID1 array, load an OS on it etc. Now,
my Asus motherboard fails. I buy a Gigabyte motherboard, that
also happens to have a SIL3112. I plug the two disks into the
Gigabyte board, set the boot order to point at the RAID
array, and it boots (subject to perhaps needing some drivers
for the other hardware, to be installed). So all I need, to
be able to get to the array again, is the same chip controlling
the ports.
For the two RAID disks, the "reserved sector" is an area of each
disk, that contains metadata about the array. Disks are tracked
by their serial numbers, and not by the ports they are plugged into.
If you had a RAID chip with six ports, you could move the two
disks to any of the six ports, and the array would still get
picked up properly. If you had a pair of disks in a stripe, which
disk is "0" and which one is "1" is recorded, so that the sectors
end up in the correct order. So everything that needs to be known,
to access the data, is stored on the reserved sectors. The only
time the reserved sector scheme fouls things up, is if it prevents
the normal layout of a disk, such that you could move a RAID disk,
to some other non-RAID chip. The location of the reserved sector,
is not something that seems to be documented, for any RAID hardware
I've read about.
I've had one experience on my current motherboard, where I discovered
that moving a disk was not portable. I had an IDE disk with multiple
partitions. I moved the disk, between a Southbridge port and my
Promise RAID controller. The RAID controller has a non-RAID mode of
operation, so in theory it works as an extra IDE port. But when I
moved the disk, I found that the first partition on the disk
"disappeared". It was not damaged, but could not be accessed again,
until it was moved back to the other controller. So don't assume
portability, until you've tested for it. The only thing that has a
reasonable chance of working, is moving non-RAID IDE or SATA disks,
between a Southbridge on one motherboard, to the Southbridge on another
motherboard.
On Mon, 15 Oct 2007 22:01:30 -0400, Paul <nospam@needed.com>
wrote:
>For example, say I have an Asus motherboard with a SIL3112 RAID
>chip on it. I prepare a RAID1 array, load an OS on it etc. Now,
>my Asus motherboard fails. I buy a Gigabyte motherboard, that
>also happens to have a SIL3112. I plug the two disks into the
>Gigabyte board, set the boot order to point at the RAID
>array, and it boots (subject to perhaps needing some drivers
>for the other hardware, to be installed). So all I need, to
>be able to get to the array again, is the same chip controlling
>the ports.
While this is true, I suggest it might be better to seek a
PCI or PCI express card with the same chip on it (though
actually, for any important data I suggest doing this
instead of relying on a motherboard integrated controller,
but part of the reasoning there is that the RAID1 is of
primary benefit for constant uptime and in that, being able
to immediately move the card plus drives to another system
is typically a reduction in downtime contrasted with having
to find/order/receive/install a new motherboard).
>
>For the two RAID disks, the "reserved sector" is an area of each
>disk, that contains metadata about the array. Disks are tracked
>by their serial numbers, and not by the ports they are plugged into.
IIRC, some don't use serial numbers but rather information
about array #, array type, and member statis within that
array. In other words, each drive independently identifies
itself as to where it is logically and whether a serial
number matches some other wouldn't necessarily matter.
>If you had a RAID chip with six ports, you could move the two
>disks to any of the six ports, and the array would still get
>picked up properly. If you had a pair of disks in a stripe, which
>disk is "0" and which one is "1" is recorded, so that the sectors
>end up in the correct order. So everything that needs to be known,
>to access the data, is stored on the reserved sectors. The only
>time the reserved sector scheme fouls things up, is if it prevents
>the normal layout of a disk, such that you could move a RAID disk,
>to some other non-RAID chip. The location of the reserved sector,
>is not something that seems to be documented, for any RAID hardware
>I've read about.
Sometimes it's the last sector on the drive. Always? I
don't know, but that would seem to make the most sense.
>
>I've had one experience on my current motherboard, where I discovered
>that moving a disk was not portable. I had an IDE disk with multiple
>partitions. I moved the disk, between a Southbridge port and my
>Promise RAID controller. The RAID controller has a non-RAID mode of
>operation, so in theory it works as an extra IDE port. But when I
>moved the disk, I found that the first partition on the disk
>"disappeared". It was not damaged, but could not be accessed again,
>until it was moved back to the other controller. So don't assume
>portability, until you've tested for it. The only thing that has a
>reasonable chance of working, is moving non-RAID IDE or SATA disks,
>between a Southbridge on one motherboard, to the Southbridge on another
>motherboard.
I've never had that problem moving a drive to/fro
southbridge to a promise card, it is good to know this
possibility of problems exists (and puzzling).
Question about RAID 1 
Linear Mode
