Hi Deb,
We use NBU here in Tucson - The majority of our data transfers are done via
NDMP... The one big drawback that I've seen is the lack of DAR (Direct
Access Recovery) in NBU. Recoveries are PAINFUL without it. (It's supposed
to be coming out this month). Veritas is the last major vendor to offer this
feature.
As for support, I'd say that it's pretty typical for the industry (I have
found that you should place a ticket at a "High" level, or you risk an
Australian tech calling your number at 2 AM...). You should expect the first
line support person to read their database before referring your case to
second-line. Again, pretty typical, and not the worst that I've encountered.
Documentation for NBU, in my humble opinion, is limited at best. Most of the
"tricks" I've learned about NBU is from calling tech support or reading this
list (thanks folks!) RTFM questions on this list are mostly due to poor
organization of the docs, and unless you're willing to spend hours finding
the particular .PDF the answer resides, it's easier to ask here. The folks
here, I've found to be professional and quite knowledgeable....
All-in-all: I miss BudTool, but I've gotten used to NetBackup.
Best Regards,
Mike
----- Original Message -----
From: "Deb" <deb AT tickleme.llnl DOT gov>
To: <veritas-bu AT mailman.eng.auburn DOT edu>
Sent: Friday, January 24, 2003 1:48 PM
Subject: Re: [Veritas-bu] Considering moving to NetBackup
> I want to thank everyone for their responsses so far - keep 'em coming
though.
>
> First of all let me respond to Jeff's inquiry, "Is there something in
> particular that's got you irritated enough to migrate an entire enterprise
to
> a different software?"
>
> A lot of things. Here's a list of just a few (from the Sun side of
things):
>
> 1. With over 200 clients, updating them from one release to the next
requires
> going to each client (via login of some kind) and doing an interactive
> pkgadd. I'm told that NBU allows client updates to be "pushed out."
This
> would save a lot of time, and be version reliable.
>
> 2. Version control is an issue with LGTO - if you get a patch for
something,
> there is not centrally located way to track which box has what patch,
and
> it is usually not in pkg format. LGTO just doesn't track version
changes,
> such as date and time and version.
>
> 3. Scripting *can* be a nightmare - while some folks love mminfo, it takes
a
> long time to get the incantations correct, and nsradmin -i is a joke,
and
> not easily scripted. There may be a perl module out there with bells
and
> whistles, but I've yet to find it.
>
> 4. Size limitations on directives.
>
> 5. Installing devices and jukeboxes are a nightmare - if you mistype
something
> in during jbconfig, you must start all over again from the beginning.
> LGTO doesn't support drive serialization.
>
> 6. LGTO doesn't support MacOS clients, NBU has support.
>
> 7. LGTO cannot stage to disk w/o purchasing an option, NBU can stage, need
> other products to to automatic staging, however.
>
> 8. LGTO writes in proprietary format to tapes, NBU is modified gnu-tar.
>
> 9. Takes forever to pre-label legato tapes PRIOR to backup. NBU does it
at
> backup time (less SA intervention).
>
> As for NDMP - that is something I am interested in - however, if NBU has
lousy
> support for that, we'd most likely use LGTO.
>
> I'd be interested in what the NBU issues are with NDMP. I didn't know
that
> there ARE issues in this area!!
>
> Comments, Suggestion, Jokes ?? :-)
>
> Thanks, guys,
>
> deb
>
|
