I can't resist. I must play too :)
1. A client / server security model based on hostname / IP address
resolution. No sane sysadmin still uses rlogin and rsh,
but NBU still uses essentially same authentication scheme. This is
vulnerable to all sorts of network attacks and if the backup
server itself is compromised, NetBackup itself can be used to compromise
any of its clients.
2. Inconsistent usage of command-line flags and switches plus a lack of
documentation on many commands.
3. Restore jobs don't report the CLIENT_NAME from bp.conf (or equivalent)
but instead use the client's hostname. (Has this been fixed in 3.4.1?)
4. Job data can only be retained for 30 days when some months have 31. Job
information needs to be archived outside of NetBackup to
track success / failure for longer periods.
5. Configuration data is spread out all over the place! (bp.conf, vm.conf,
job.conf, the windows registry, version files) and everying is in a different
location. (Can't we have a single consistent configuration file format
like Apache?)
6. Duplications with bpduplicate don't show up in the job monitor and can
only be monitored by logfile.
7. NBU doesn't allow more than 2 copies of a backup image! If I stage to
disk and want two copies on tape, I can't make each copy from disk
to tape. Instead, I have to make the 1st copy to tape from disk, then
expire the copy on disk, then copy the 1st from tape to tape.
8. Pre and post backup commands, as well as include / exclude lists, are
defined on the client. They should be centrally manageable from the
server. The client should be a dumb stub with the server telling it what
and what not to do.
9. The interface to extended debugging information needs to be better than
creating subdirectories and looking at filenames with a text editor.
There should be a facility to view all errors from a single console in
realtime when working on a problem.
10. With all its faults, NetBackup is still one of the best products out
there. Although it is an unruly beast, it is usually possible to beat it into
submission easier than with other products. Hopefully Veritas will listen
to us :)
Regards,
--PLB
At 09:02 AM 01/24/2002 -0500, Prasad Chalikonda wrote:
>You go Bob!!!!! I second that.
>
>
>Prasad.
>
>
>Metcalf, Bob wrote:
>
>>Here's my gripe....
>>
>>How about a pathc-level Matrix on the bloody
>>web site? How hard is this:
>>
>>Solaris7 server, NBpatchXXX, NBpatchYYY
>>NT4SP6 server, NBpatchHHH, NBpatchTTT
>>
>>Is there anybody out there that can claim
>>to actually make sense of the current page?
>>
>>-----Original Message-----
>>From: Miriam Ben-Haim [mailto:miriam AT techunix.technion.ac DOT il]
>>Sent: Thursday, January 24, 2002 2:55 AM
>>To: Fabbro, Andrew P
>>Cc: veritas-bu AT mailman.eng.auburn DOT edu
>>Subject: Re: [Veritas-bu] Top 10 Things I Hate About NetBackup
>>
>>
>>
>>
>>I would add:
>>
>>full backup should not expire as long as other backups depending on
>>it are not expired, even if its original expiration date arrived.
>>
>>and
>>
>>update and install clients' software with ssh rather than rsh.
>>
>>
>>
>> Miriam
>>
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Miriam Ben-Haim E-mail: miriam AT technion.ac DOT il
>>Unix Systems Phone : +972-4-8292177
>>Taub Computer Center Fax : +972-4-8236212
>>Technion - Israel Institute of Technology, Haifa 32000, ISRAEL
>>
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>On Wed, 23 Jan 2002, Fabbro, Andrew P wrote:
>>
>>>Entertaining myself here at lunch, I present, in no particular order...
>>>
>>>10. Can't set exclude lists at the master, only at the client. Very silly.
>>>I would like to exclude, say, /tmp or WIN386.SWP on all clients in a class
>>>but I can't...instead, I have to make sure the exclude file is correct on
>>>each client. What a nightmare for large environments. Some admin adds a
>>>client (that I may not have access to check his setup) and doesn't set his
>>>exclude list properly. Now I'm chewing tapes for nothing, or worse, not
>>>backing up something he needs. What was the thinking here? Particularly
>>>since the raw Class database shows an Exclude field ;)
>>>
>>>9. "Use any available media server" doesn't round-robin. Strange but true
>>-
>>
>>>it works the list of media servers *alphabetically*. If you have multiple
>>>media servers, then NetBackup will attempt to use all of the drives on #1,
>>>then go on to #2, etc. If one of the drives in #1 becomes free, then it'll
>>>use it before going back to #2. So if you have multiple media servers and
>>>want to distribute the load, it's difficult to do so because your full
>>tapes
>>
>>>will naturally accumulate in the first (alphabetically speaking) storage
>>>unit.
>>>
>>>8. Can't restart just one stream. If a single stream fails, you have to
>>>rerun the whole backup job. Blech. Why can't I restart just that one
>>>stream?
>>>
>>>7. The X-windows backup/restore GUI doesn't have a "preview media required"
>>>feature for a restore. The Java backup/restore GUI doesn't show you a list
>>>of the backup images. I wish there was one that did both ;)
>>>
>>>6. bpinject sucks. I think bpinject is only packaged with bpvault. The
>>>design is really amazingly bad. The idea is that you can type "bpinject 2"
>>>and it'll dump the cap from robot 2 into the robot. However, if that robot
>>>is on another machine, then you need to have root-level .rhosts access to
>>>it. Oh sure, let me rewrite our site security policy so I can insert tapes
>>>- har! This is a particularly bad design because you can use Netbackup's
>>>vmchange to insert the tapes through NetBackup. The only reason you need
>>>.rhost access is to query the robot - I'm opening my whole system up just
>>so
>>
>>>you can query the robot!?!?
>>>
>>>A better solution is simple:
>>>
>>> - write a service on the media server that runs out of inetd that
>>>reports the status of the robot. Takes
>>> about 100 lines of perl.
>>> - when the bpinject script needs to know what the status of the
>>>robot is, it can connect to this service
>>> and query the status of the robot, then use vmchange (vmadd, etc.)
>>>to insert tapes.
>>>
>>>5. jnbSA sends the root password in the clear. Come on people, this is
>>2002
>>
>>>- how hard would it be to encrypt this?
>>>
>>>4. Frequency for hours, days, and weeks...but not months! How can I do
>>once
>>
>>>a month? I can do every 4 weeks, but that doesn't really work because
>>>there's an extra week every quarter.
>>>
>>>3. Stupid bug - put in a path like "/somewhere/someplace/blah ". Note
>>the
>>
>>>blanks. Now run a coverage report. Note that this is reported as
>>>"UNCOVERED". Sheesh. Also, if you put "C:" in a file list, you'll get
>>only
>>
>>>the "Veritas" folder on C:. If you put "C:\", though, you get everything.
>>>
>>>2. Archive doesn't make two copies, only one. Considering that you're
>>>blowing the data away from disk, I'd feel better if it was written to two
>>>tapes, but NetBackup only does one. I wish this was configurable.
>>>
>>>1. It's still better than any other product on the market.
>>>
>>>
>>>_______________________________________________
>>>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
>>
>>_______________________________________________
>>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>_______________________________________________
>>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
