[Veritas-bu] /usr/openv placement

[Jeff Kennedy]

Ok, so why?  We run numerous EDA applications from a filer and have no
issues with that, why would NBU be any different?  And when you add the
management and functionality bonuses I mentioned I would think it would
be a prefered method.  I'm not slamming, I just want your reasons (to
make sure you've thought this through...;-])

~JK

"David A. Chapa" wrote:
> 
> I like NetApps for certain applications, NBU is not one of them.
> 
> My opinion is that I prefer direct attached storage (or nearly direct) for
> NBU, NFS doesn't qualify in either camp.
> 
> I'm sure its been done and done successfully, I'm just not a fan of it.
> 
> My two cents.
> 
> David

> -----Original Message-----
> From: veritas-bu-admin at mailman.eng.auburn.edu
> [mailto:veritas-bu-admin at mailman.eng.auburn.edu]On Behalf Of Jeff
> Kennedy
> Sent: Friday, October 05, 2001 1:58 PM
> To: Veritas-bu List
> Subject: [Veritas-bu] /usr/openv placement
> 
> I am contemplating putting the entire /usr/openv partition on a NetApp
> filer.  My reason is that currently my images directory is 68gb's, and
> this is not yet including the new filer I am adding nor the 5 Novell
> servers that will be added in the next week or so.  Once that happens I
> will be looking at much more then 68gb's for images.  I do not want to
> have to waste time backing up this data every time a scheduled backup
> finishes, plus it wastes tape when I'm sending them offsite every week.
> 
> What I'm planning is to have all the NBU stuff on the filer and
> snapmirror that data to a remote site.  This way I can recover
> completely to another site in case of total disaster, or I can
> snapmirror the entire structure back here if needed, or I can just copy
> back the images I need.  My WAN pipe between these sites is big enough
> that the difference in recovering from an offsite db backup and
> snapmirroring the entire structure back is negligable.
> 
> Any thoughts, opinions, experiences?
-- 
=====================
Jeff Kennedy
Unix Administrator
AMCC
jlkennedy at amcc.com