Veritas-bu

[Veritas-bu] Re: Request for comments

2002-01-22 12:39:19
Subject: [Veritas-bu] Re: Request for comments
From: bhhorn AT creighton DOT edu (Brian Horn)
Date: Tue, 22 Jan 2002 11:39:19 -0600
I always thought it would be quite handy for the "Activity Monitor" to
note whether or not there were duplications occuring.  And also
explicitly note that a backupdb was active.


> 
> Message: 8
> Date: Tue, 22 Jan 2002 15:49:02 +0100
> To: veritas-bu AT mailman.eng.auburn DOT edu
> From: "Peter L. Buschman" <plb AT iotk DOT com>
> Subject: [Veritas-bu] Request for Comments - Unix/NT Perl Interface to 
> NetBackup
> 
> Fellow NBU Users:
> 
> I would like to pose the following question to the list:
> 
>          "What features would you most like to see in a perl interface to
> NetBackup?"
> 
> As a perl programming exercise, I have been working on an abstract module
> that provides read-access
> to nearly every piece of configuration and index data within NetBackup.  I
> have also successfully ported
> the module to Windows such that scripts that use the module can run
> un-modified on both Unix and NT
> platforms (so far tested only on Solaris and Windows 2000.)
> 
> To date, I have even surprised myself at how well this programming exercise
> has functioned, to the point
> that I think some of you folks out there might be able to make some use of
> this code (under a suitable open
> source license, of course.)
> 
> I have abstracted the following commands in their entirety, returning their
> output in easily-parsed perl
> hash structures (in particular, I fully parse the dreaded bpdbjobs
> -all_columns output, returning every single
> field.)  All functions can be passed search parameters that take advantage
> of perl's powerful matching syntax
> to return desired subsets of data (ideal for creating functions that
> monitor objects created in a certain time
> period....like for a daily job success/failure report.)
> 
> ##   /usr/openv/netbackup/bin/goodies/bperrcode
> ##   /usr/openv/netbackup/bin/admincmd/bpclclients
> ##   /usr/openv/netbackup/bin/admincmd/bpdbjobs
> ##   /usr/openv/netbackup/bin/admincmd/bpimagelist
> ##   /usr/openv/netbackup/bin/admincmd/bpmedialist
> ##   /usr/openv/volmgr/bin/vmpool
> ##   /usr/openv/volmgr/bin/vmquery
> ##   /usr/openv/bin/admincmd/bpconfig
> ##   /usr/openv/bin/admincmd/bpgetconfig
> ##   /usr/openv/bin/admincmd/bpstulist
> ##   /usr/openv/bin/admincmd/bpcllist
> ##   /usr/openv/bin/admincmd/bpsyncinfo
> ##   /usr/openv/volmgr/bin/vmglob
> ##   /usr/openv/volmgr/bin/tpconfig
> 
> Furthermore, version information and other details stored in various text
> files are accessible.
> 
> What I would like to know is this:
> 
> Would anyone be interested in this?  (I still have some documentation I
> need to write on basic usage
> since this is still just a low-level toolkit, but I have written a few
> example scripts that illustrate the power
> of the API.)
> 
> If there is interest, what features would you like to see added in the
> future?  I am rather enjoying this as
> a fun programming project and am looking for suggestions as to where to go
> with it.  Since I spend my
> free time doing this, I might as well code up things that other people find
> useful.
> 
> A few things that have come to mind include:
> 
>          + A reporting framework a'la NetBackup Advanced Reporter.
>          + Porting a number of the monitoring scripts that are out there so
> they are cross-platform.
>          + Adding command and control functions.
>          + An NBU configuration auditor that looks for common problems and
> errors.
> 
> If there is enough interest, I will look at setting up a mailing list for
> cross-platform backup programming issues
> (I'd eventually like to create toolkit interfaces to Legato
> Networker,  Tivoli Storage Manager, and others, allowing
> some application-independent tasks like media managment to be handled
> uniformly, but I am getting way ahead
> of myself there.)
> 
> --PLB
>

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] Re: Request for comments, Brian Horn <=