"Nothing is a substitute for backups."
I just want to reiterate this, hardware fails. If properly managed you may be 
able to identify the failure before any damage is done. And, a viable offsite 
backup mitigates things like a house fire.But, in any case, backups are a last 
resort, but tried and true. 
 

On 06/20/2014 09:15 AM, Edward Ned Harvey (blu) wrote:
>> From: [email protected] [mailto:discuss-
>> [email protected]] On Behalf Of Stephen Adler
>>
>> Any comments on how to deal with say a 16 disks and what's the current
>> lore on making large redundant disk arrays?
> However you decide to do your redundancy, try to eliminate as many single 
> points of failure as possible.  For example, I strongly prefer to use ZFS, 
> with mirrors, where each disk is mirrored to another disk on a different bus. 
>  For these setups, I prefer absolutely dumb SATA/SAS buses with no hardware 
> raid, buffering, caching of any kind, so those disks can be plugged into any 
> dumb SATA/SAS system.  That way if you have an entire HBA fail, you still 
> have your filesystem up and running.
>
> If you're doing hardware raid, you probably won't be able to distribute the 
> redundancy across separate buses (but you can get redundant HBA's on things 
> like SAN's, with multipath, if you have the budget for it).  But assuming 
> you're talking about an individual server with an individual HBA, then just 
> make sure you have a super awesome warranty on that system, because the HBA 
> will do something proprietary, and the only sure way to ensure recovery after 
> replacing a failed HBA is to have a fully supported compatible (identical) 
> replacement HBA.
>
> Actually depending on the mode of failure, a failing HBA can also spray 
> garbage bits all over the disks before its brains explode violently, thus 
> rendering any recovery impossible even if you have a fully supported 
> compatible or identical replacement HBA.
>
> Nothing is a substitute for backups.
>

-- 
Jerry Feldman <[email protected]>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90


_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss

Reply via email to