How to determine my jobs ran?

[ctate]

I have 2 Netbackup 6.0 Windows environments.  I want to verify that the backups I have scheduled actually run.  I know I can run nbpemreq -predict -date 12/04/2007 to determine jobs to run today for example.  I was thinking I could run a bpdbjobs command and cross reference the two, but the format that bpdbjobs gives me either lists too much information or not enough information depending on the switches I use.  Does anyone know how to automate this or is their a command that will verify scheduled jobs actually did run? 

Thanks.

[Roobix_Cube]

Why don't you run either of the following:

Backup Status Report
The Backup Status report shows status and error information on jobs completed within the specified time period. If an error has occurred, a short explanation of the error is included. 
# /usr/openv/netbackup/bin/admincmd>./bperror -U -backstat -s info [-d <start_date> <start_time> -e <end_date> <end_time>]

Client Backups Report
The Client Backups report shows detailed information on backups completed within the specified time period. 
# /usr/openv/netbackup/bin/admincmd> ./bpimagelist -U [-A|-client name] [-d <start_date> <start_time> -e <end_date> <end_time>]

[ctate]

Thanks for the information, but will that tell me if a job did not run.  If a job doesn't run due to some type of scheduler issue then there are no errors to look at.  I had this problem in 4.5 and 5.1 (maybe) where I saw no errors in activity monitor, but the jobs never ran when they were scheduled and I didn't know it until I need to do a restore.  Luckily, this never bit me.   We had an old script that would tell us if a job didn't run that remedied the problem becasue I could look at that report to confirm everything ran, but the script doesn't work anymore because the commands are different in 6.0.

[bcblake]

You could try checking bpdbjobs every so often from cron, and keep track of the job ID numbers. Yes, it's a pain but I've worked with customers that have done this.

With 6 you should not have as much of a problem with it as the scheduler has been re-written... that being said, it's still possible, just less likely. The problems in 4.5 and 5.x usually stemmed from either a lot of media servers, network issues, a really busy master etc... bpsched stuffs a bunch of requests into a message queue, and then reads them out of the other side. If the master is busy, or bpsched is waiting on hearing back from a media server (by checking in with bptm), then it has to process those requests sequentially from the message queue. bpsched is a single-threaded application, and one of the ways around it in the past was to get a faster master server (or faster processor for the master)... or change the configuration so that the master wasn't as busy. Keep in mind that the master might have to service a lot of vmd requests as well, which can become very significant as the number of media servers increases.

Brian