[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] backup/restore mail from USB external drive

Because the probability of having an unrecoverable read error on RAID5 
rebuild starts to come up off the peg and RAID6 isn't much better.

Since they came on the market, I've found that NASses both cheap (e.g., 
LaCie) and expensive (IBM-rebadged NetApp where you paid extra by the 
protocol) aren't worth spit.  Sure, they work (sort of - I got a LaCie 
guy to admit to me once that their NFS implementation was badly broken 
but they didn't really care), but the sorts of things you may expect to 
do administratively, like make fast copies internally, scan for viruses, 
or search for files (for instance, because someone had an errant mouse 
drag that moved their quarterly report spreadsheets to God-knows-where) 
are ruinously slow.  To give you some idea, I once replaced said 
rebadged NetApp - that cost about $40,000 - with a SuperMicro-based 
Gentoo Linux file server with a mix of SAS and SATA drives in 24 slots 
in the front, two SSDs inside, two SAS controllers (with RAID10 with the 
RAID1 pairs split across controllers so a controller would die and you 
still wouldn't lose the volume), and two four-core CPUs.  All that plus 
a warm-swap machine, spare mobo, spare CPUs, power supplies, NICs, disk 
controllers, and RAM (to heck with waiting for some schmoe from e.g. 
IBM's field service contractor to find your site and replace parts in a 
machine he might have never seen before anyway) cost about $25K, and it 
could scan its main shared-space volume with clamav at over 200MiB/s.  
In-slot NICs were bonded for I/O (the on-mobo NICs were not used in 
order to reduce the risk to the mobo).  It was NFSv3-ready, had Samba of 
course, and daemons for anonymous chrooted FTP and rsync - and there was 
talk at one time of having it serve out CVS (it'd might as well!).

So when you talk to me about what RAID configuration I'd recommend for 
12x2TB drives in a NAS, I'm thinking of the operational risks you've 
baked into your IT resources just by having a NAS in the first place and 
wondering whether or not RAID nuances would matter all that much at the 
end of the day.  Ask yourself this:  even if it were just half full, how 
long would it take you to do a complete read for backup-making 
purposes?  See, in this day and age, it's real easy to have giant 
amounts of storage and therefore giant amounts of stuff being stored, 
all connected to everything else by what are very tiny pipes, relatively 

On 2/12/14, 6:43 PM, Ray Vastly wrote:
> Why should you avoid raid 5 or 6 when using large hard disks? What 
> Raid configuration would you recommend for 12 HDDs each 2 TB in a NAS?
> On Feb 12, 2014 6:40 PM, "Jeff Hubbs" <jhubbslist at att.net 
> <mailto:jhubbslist at att.net>> wrote:
>     On 2/12/14, 5:00 PM, Lightner, Jeff wrote:
>>     <snip>
>>     You really should be using RAID6 or RAID10 rather than RAID5 as
>>     it is even more redundant (i.e. can survive 2 disks failures).
>     And you shouldn't be using RAID5 or RAID6 at all if your drives
>     are 750-1000GB or larger.
>     Mail and database servers would be two good places to make use of
>     snapshotting filesystems.  Note that some email systems that use
>     message stores go insane if the message store is not in the state
>     that the rest of the email system presumes it's in, so you have to
>     make sure that your backup/recovery scheme doesn't capture
>     messages and message metadata/index in different states.
>     _______________________________________________
>     Ale mailing list
>     Ale at ale.org <mailto:Ale at ale.org>
>     http://mail.ale.org/mailman/listinfo/ale
>     See JOBS, ANNOUNCE and SCHOOLS lists at
>     http://mail.ale.org/mailman/listinfo
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140213/5ae1a3fb/attachment-0001.html>