Home Office Server Security

[Carruth, Rusty]

Well, yes and no.

 

If you have 5 drives in a RAID 5 array, then “1 drive is parity”  (yes, I know that some implementations move the parity around among drives, lets ignore that for now and pretend that one drive has all the parity info).

 

I was speaking of the case where you have already lost one drive (since you are trying to recover), then you have NO protection against failure of another drive.  You’ve lost one, and now you want to rebuild.  There must be no failures on all LBAs of all remaining drives.  I don’t know if it has changed, but at one point a failure to rebuild ONE SINGLE LBA (512 bytes) would result in total failure to rebuild.  Silly, but that was my understanding.

 

(If you have 3 drives in a RAID 5 array, then you still have only 1 as ‘parity’, and so forth.  Now, you CAN (I think) have 2 ‘parity’ drives so that if you lose 1 drive you still have the ability to recover since you still have parity)

 

Sorry that was unclear.

 

From: plug-discuss-bounces at lists.phxlinux.org [mailto:plug-discuss-bounces at lists.phxlinux.org] On Behalf Of Eric Cope
Sent: Wednesday, April 03, 2013 10:10 AM
To: Main PLUG discussion list
Subject: Re: Home Office Server Security

 

Your RAID5 recover statement is incorrect. You only need 4 of the 5 drives to recover. However, if 2 drives fail, all data is lost.

 

On Wed, Apr 3, 2013 at 10:04 AM, Carruth, Rusty <Rusty.Carruth at smartstoragesys.com> wrote:

Very good rambles!  See my comments (well, rambles) below.


> -----Original Message-----
> Subject: Re: Home Office Server Security
>
> semi-coherent ramblings follow - I wanted to give you some stuff to
> consider
>

...

> Use whatever RAID you are comfortable with.  I've tried RAID5 and
> RAID1, and RAID1 is by far the easiest to recover from.  RAID0 is a
> disaster waiting to happen.  Some people have had no problems with
> RAID5, but it seems almost as many find RAID5 such a PITA that they
> swear "never again!"
>
> I did RAID1 with two drives bought at the same time.  Sure enough one
> drive failed, and I was too busy to address it.  A couple months later
> the other drive failed.  Duh!  Same drive manufacturer, same model,
> almost same manufacture date - yeah, I asked for that.  You might want
> to use different drive manufacturers to mitigate that risk.
>

Remember the theory behind RAID is that two 'independent' drives will
fail at different times.  Is that a valid assumption? I'm not convinced

The problem with raid 5 is that, in order to recover the array ALL
DRIVES in the array must be 100% functional or your rebuild will fail
and you lost your data anyway.  (of course, if you have more than one
'parity' drive then things are different).

Raid 1 is similar, really, but may not be as fatal if you lose one
block.  I've not tried it nor thought much about that, so I may be
wrong.

The purpose behind 5 is to save money, I think.  The question I have is
- how important is your data?  If it's important enough to want to have
redundancy, why is it not important enough to use RAID 1 with 2 OR MORE
drives?  Too expensive?  Then be certain you have a good backup system!
(Oh, my, look!  A backup system will be another copy of all your data.
Taking the same space (or maybe less because of using gzip or other
compression).  Wow, 2x the disk space! Saved lots of money, did we? :-)
Of course, the backup system can be slower and cheaper drives... wait,
how important was this data???)

Rabbit trail: But the ability to restore a directory you 'oopsed' is
probably worth the cost, and RAID doesn't give you that ability.

So, in summary, I'm saying that almost all decisions are tradeoffs
between cost, risk, time, and probably other stuff.  "You pay your
money, you make your choice" :-)

Rusty

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130403/a2f559cd/attachment.html>