Backup Central

Gang,

Is there an equiv to the backup_exit_notify script that provides more
information than just 'client' 'schedule', 'schedule_type', etc?

I'm still kind of a noob when it comes to this stuff, so bear with me if
this is a dim question. :)

Some of the backups we do (namely oracle) generate quite a few calls to
the script, and I'd like to be able to figure out which specific backup is
calling it. The same would go for clients that don't use "ALL_LOCAL_DRIVES"
as the 'stuff to backup'.

What I'm trying to do, is tie this to a snmp-trap and generate traps
with backup status and tie it all into Nagios (yea, there are other ways to
do this, but snmp sounded like fun when I started this project..)

Since Veritas has been .. Less than helpful with specifics on the
snmp-agent for Veritas products, I figure I'd go ahead and roll myo own.
Besides, now that Symantec owns Veritas, I figure if I bought anything new
from them It'll stop working 12 months after date of install with errors
about renewing my live-update subscription. :)

So, what I'm looking for, is a way to catch either the specific oracle
backup, or filesystem path that's being backed up along side the standard
'client', 'schedule', 'schedule type', 'status', 'stream id' information (I
prolly missed one in there..)

I assume that this is a fairly common thing to do, so someone out there
has got to have a few pointers (or instructions..or a tarball.. .


Thanks,
-Jeff

<quote who="Jeff McCombs">
Gang,

Is there an equiv to the backup_exit_notify script that provides more
information than just 'client' 'schedule', 'schedule_type', etc?


This is pretty funny because I was about to send my own query to the list
about backup_exit_notify. I'm annoyed because according to the printed
docs, it executes when the backup is finished. Upon checking the Technotes
(and the sample installed with NBU), I see that it also tells you the
stream number.

I just want to know when the entire backup is completed, but
backup_exit_notify doesn't seem to have any idea about how many streams
were included in this job.

Digging around trying to think of an answer to both of our problems, I
thought of using the execution of backup_exit_notify as a signal to use
bperror to find out more information.

My thought process is:

1. backup_exit_notify gets called

2. Use bperror to try to track down information on the job that just
completed:
bperror -client <client> -d <now - 5 minutes> -e <now>

3. Parse through that output looking for the 'bpsched' line that matches
the client, schedule, policy, and exit status that you received through
backup_exit_notify. That should give you the primary job ID and secondary
job ID if it was a job with multiple streams.

4. You can then call bperror again with the -jobid switch and look for the
matching 'handling path' lines that come from bpsched.

Can anyone think of a classier/neater way of doing this?

--
Michael Barrow
michael < at > mlbarrow.com

On Mon, Jan 24, 2005 at 09:07:10PM -0500, Jeff McCombs wrote:
Some of the backups we do (namely oracle) generate quite a few calls to
the script, and I'd like to be able to figure out which specific backup is
calling it. The same would go for clients that don't use "ALL_LOCAL_DRIVES"
as the 'stuff to backup'.

What I'm trying to do, is tie this to a snmp-trap and generate traps
with backup status and tie it all into Nagios (yea, there are other ways to
do this, but snmp sounded like fun when I started this project..)

The bottom line is that you're in for a lot of development work because
the hooks just aren't there yet. It's not like customers haven't asked
but it hasn't made it to the top of the development priority list.

We took what is probably the easier way out - purchase Aptare's
StorageConsole product. It answers the really basic question of whether
your backups were successful or not (by mount point even) and lets you
see at a glance what the health of your backups is. It does a lot more
than that too. It's commercial but we've found it extremely worthwhile.

.../Ed

Disclaimer: I'm just another customer. I don't even have an Aptare
T-Shirt :-)

--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts < at > ewilts.org

I've altered the backup_exit_notify to run a kixtart script file if the
return code wasn't 0. Inside of this script file it runs the bperror on the
client that was backed up and emails the log to our team. I do this so
we'll know as soon as a backup fails on a client. No email is sent if the
backup is successful.

Once a night I run an automated task that runs a bperror of the previous
nights' backup of each client we backup with netbackup. It reads a file to
get a list of the client machines to run the bperror against. I actually
run two bperror commands against each client. One to get a one line output
of the job status and one to get the entire log so I end up with two output
files. The smaller file which contains the one line status of each job is
altered by the script so there will only be one header line and only the one
line output of each job ran under that. I email that attached file to my
team. Also inside this email is a link to the file with the entire backup
status of each client in it.

-----Original Message-----
From: veritas-bu-admin < at > mailman.eng.auburn.edu
[mailto:veritas-bu-admin < at > mailman.eng.auburn.edu] On Behalf Of Michael L.
Barrow
Sent: Wednesday, January 26, 2005 12:03 PM
To: Jeff McCombs
Cc: veritas-bu < at > mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Backup_exit_notify script / snmptraps...


<quote who="Jeff McCombs">
Gang,

Is there an equiv to the backup_exit_notify script that provides
more information than just 'client' 'schedule', 'schedule_type', etc?


This is pretty funny because I was about to send my own query to the list
about backup_exit_notify. I'm annoyed because according to the printed docs,
it executes when the backup is finished. Upon checking the Technotes (and
the sample installed with NBU), I see that it also tells you the stream
number.

I just want to know when the entire backup is completed, but
backup_exit_notify doesn't seem to have any idea about how many streams were
included in this job.

Digging around trying to think of an answer to both of our problems, I
thought of using the execution of backup_exit_notify as a signal to use
bperror to find out more information.

My thought process is:

1. backup_exit_notify gets called

2. Use bperror to try to track down information on the job that just
completed:
bperror -client <client> -d <now - 5 minutes> -e <now>

3. Parse through that output looking for the 'bpsched' line that matches the
client, schedule, policy, and exit status that you received through
backup_exit_notify. That should give you the primary job ID and secondary
job ID if it was a job with multiple streams.

4. You can then call bperror again with the -jobid switch and look for the
matching 'handling path' lines that come from bpsched.

Can anyone think of a classier/neater way of doing this?

--
Michael Barrow
michael < at > mlbarrow.com



**********************************************************************
The information contained in this communication is
confidential, is intended only for the use of the recipient
named above, and may be legally privileged.
If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly
prohibited.
If you have received this communication in error,
please re-send this communication to the sender and
delete the original message or any copy of it from your
computer system. Thank You.

------=_20050126170301_83559
Content-Transfer-Encoding: 8bit

<quote who="Jeff McCombs">
Gang,

Is there an equiv to the backup_exit_notify script that provides more
information than just 'client' 'schedule', 'schedule_type', etc?


Not hearing any ideas to the contrary, I threw together a little Perl
script to codify the logic that I suggested earlier. It's attached. I'm
still open to find out if anyone has a better way of doing this.
--
Michael Barrow
michael < at > mlbarrow.com
------=_20050126170301_83559