Networker

Re: [Networker] Cloning from Disk

2006-07-17 17:42:56
Subject: Re: [Networker] Cloning from Disk
From: Preston de Guise <enterprise.backup AT GMAIL DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Tue, 18 Jul 2006 07:39:13 +1000
Hi Librado,

On 18/7/06 1:02 AM, "Librado Pamintuan" <LPamintuan AT REGINA DOT CA> wrote:

> Here's how I partitioned the AX100i. We ordered it fully loaded with 12x 500GB
> SATA drives (7.2 RPM).
> - created 1 large pool RAID 5 (11 disks with 1 hot spare) 5 TB RAW capacity
> - created 3 virtual disks out of this 1 large disk pool.
>   - 2x 2TB and 1x 450 GB LUNs.
> 
> 
> Somebody already suggested before that you can get better performance on
> smaller LUNs (1TB or less), but the only issue I can see is the administration
> part, need to relabel or reinitilize the adv_file device more often. Right
> now, I only need to relabel my disk device at least once a week and it will be
> able to hold/save a week's incremental backups and the weekend full backups.
> 
> 
> This is also a limitation of NetWorker DBO, even if you have multiple disk
> devices, it will not automatically mount another one if the one which is
> currently mounted/used filled up.

EMC has had various whitepapers suggesting that the best configuration for
disk backup units is a series of 5-disk RAID-3 or RAID-5 groups. Having
watched some recent customer experiences I'm inclined to suggest RAID-5 is
somewhat more reliable and RAID-3 only outperforms in certain situations.
This is certainly meant to help with simultaneous read/write performance,
but in general ATA drives don't work well in this situation. I've only seen
customers who are able to devote money to fibre drives for disk backup
entirely escape the "good read performance", "good write performance", "no
performance when doing both" scenario.

The general rule of thumb I've followed is that DBUs should be twice as
large as your largest saveset + some room for error. For example, if the
largest individual saveset a customer might have is 600GB I might recommend
that their DBUs should be at least 1200GB + another 15-20% _formatted_ so
that if the same saveset is written twice there's at least a _chance_ that
it'll not fill the disk (i.e., a full weekly cycle sort of scenario).
Obviously there's a lot of ifs in there, and few guarantees, but it's a good
starting point.

The only challenge I see with striping at the operating system, as some
suggest, is that you then only need one presented LUN to go offline for some
reason and your entire disk backup filesystem may become corrupt --- not
nice...

(The inability to fail over between disk backup units is (rightly or
wrongly) I believe an inherent design failure at the present time in nsrmmd.
If EMC would devote some time to allowing nsrmmd's to proxy for one another
you'd find that a whole set of problems would go away through transfer of
savesets between devices.)

Cheers,

Preston.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu 
if you have any problems
wit this list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER