Setting BPSTART_TIMEOUT for opscenter

[mikebounds]

As I understand "/usr/openv/netbackup/bin/bpstart_notify" does not exisit by default, but if it exists it gets called at the start of a backup.  We have opscenter installed and this creates this file so when we try to back up the opsceter server, it fails as the script times out.  

The bpstart_notify script runs "/opt/SYMCOpsCenterServer/bin/dbbackup.sh /ops-backup -v" and I have run this manually and it takes 38 mins

The bpstart_notify script says:

# If this script will not complete within a few seconds, you should set
# the BPSTART_TIMEOUT in the /usr/openv/netbackup/bp.conf file on the server.

So this reads as if you set  BPSTART_TIMEOUT on the server running the script, but I tried this and it has no effect, but after reading the manual, this says it needs to go on the master so I set this in the Java GUI (NetBackup Management > Host Properties > Double-click on master server > Timeouts > Backup start notify timeout) and also set CLIENT_READ_TIMEOUT, both to 3600 and after setting the GUI says:

Some setting may not take effect until daemons or services are restarted.   See documentation for further details

I have read the "Timeouts properties" section in the "Admin I" manual and there is no mention of restarting the daemons for ANY of the timeouts, but after re-running the backup for the Opcenter backup server, it still fails with the old timeout.

So I have the following questions:

1. We run about 200 jobs a day and opscentre backup takes about a minute to back up but then it validates taking over 35 mins to validate the 1GB vxpmdb.db produced - is this normal?
    
2. Where is the document that the GUI references which tells me which timeouts require which daemons to be restarted?
    
3. I don't mind BPSTART_TIMEOUT being set for all hosts as the Opcenter server is the only backup client running the bpstart_notify script, but I am not happy setting CLIENT_READ_TIMEOUT.  If it is ok for all 200+ clients to have a CLIENT_READ_TIMEOUT of 40 - 60 mins, then why not make this the default - so I supect this is NOT ok which is why it is 5 mins by default, so can I avoid setting CLIENT_READ_TIMEOUT for all 200 clients, just because 1 clients takes longer

Thanks

Mike

[RamNagalla]

1. We run about 200 jobs a day and opscentre backup takes about a minute to back up but then it validates taking over 35 mins to validate the 1GB vxpmdb.db produced - is this normal?

Does not look Normal, we have 36GB Opscenter DB which is compleating its backup in 60 minitues to ints local Drive, and its windows 2008 R2 server..  so considering this i dont think 35 Min for 1 GB is not normal.

2         Where is the document that the GUI references which tells me which timeouts require which daemons to be restarted?

admin guide would be the one, since you have already go through that, i am not sure if there is a specific document.. however Most of the modifications does not require restart when we do it from GUI

3       I don't mind BPSTART_TIMEOUT being set for all hosts as the Opcenter server is the only backup client running the bpstart_notify script, but I am not happy setting CLIENT_READ_TIMEOUT.  If it is ok for all 200+ clients to have a CLIENT_READ_TIMEOUT of 40 - 60 mins, then why not make this the default - so I supect this is NOT ok which is why it is 5 mins by default, so can I avoid setting CLIENT_READ_TIMEOUT for all 200 clients, just because 1 clients takes longer

I understanding setting the timout value for 200 clients however it will only wait that long only if it does not hear from the client... as long as you have healty clients they respond quickly and this value will be invalid for those..

so i would say you can go ahead and set it.. 

[mikebounds]

I have done some more investigation - the bpstart_notify has a header with:

#* $VRTScprght: Copyright 2013 Symantec Corporation, All Rights Reserved $ *

and this runs:

/opt/SYMCOpsCenterServer/bin/dbbackup.sh /ops-backup -v

and dbbackup.sh has a header:

# $Copyright: Copyright 1993 - 2012 Symantec Corporation, All Rights Reserved $

So it looks like both files are provided by Symantec, presumebly by Opscenter (as oppose to some custom scripts), but there is a number of issues with this script:

1. It runs for all policies, so runs for an OS policy which is not even backing up the filesystem containing the database dump
    
2. The "-v" option to dbbackup forces the "validate" function, but the validate function does not return the exit code of the validate command and the code that calleds the validate function does not check for a return code, so if the validate fails, the backup will still continue so the validate would appear to be a waste of time to me so I have removed the "-v" option from the bpstart_notify script so now the bpstart_notify takes less than 2 mins to run so no problems with timeouts.

The above is an Opscenter issue, but in terms of NBU it seems the:

Document reference by the GUI does not tell you if daemon needs to be restarted and a new jobs still times out with the old timeout. so I guess restarting daemons is necessary for this timeout.

Mike

[sdo · Accepted solution]

You can use a bpstart_notify[.POLICYNAME[.SCHEDULENAME]] script so that the script only runs for a specific policy and/or schedule.

Also, you may want to see my notes (in the script) here, re multiple streams here in a Windows example:

https://www-secure.symantec.com/connect/downloads/example-netbackup-bpstartnotify-script-take-opscenter-server-database-backup

...as I'm pretty sure you'll have similar concerns with multi-streaming in Unix land.

[mikebounds]

Thanks sdo - I have renamed  bpstart_notify so now it only runs for the policy I want.

Mike 

[sdo]

Are you handling 'multiple stream' instances too?  Or does your backup policy only ever create one stream?

[mikebounds]

The answers to my original questions in my opinion are:

1. We run about 200 jobs a day and opscentre backup takes about a minute to back up but then it validates taking over 35 mins to validate the 1GB vxpmdb.db produced - is this normal?
   The time the validate takes will be to do with size of DB and performance of server and so as we have a fairly small DB, opscenter is on a fairly small server, so I think 35 mins is normal
    
2. Where is the document that the GUI references which tells me which timeouts require which daemons to be restarted?
   The Document referenced by the GUI does not tell you if daemons needs to be restarted and new jobs still time out with the old timeout after I changed the BPSTART_TIMEOUT, so I guess restarting daemons IS necessary for the BPSTART_TIMEOUT timeout
    
3. I don't mind BPSTART_TIMEOUT being set for all hosts as the Opcenter server is the only backup client running the bpstart_notify script, but I am not happy setting CLIENT_READ_TIMEOUT.  If it is ok for all 200+ clients to have a CLIENT_READ_TIMEOUT of 40 - 60 mins, then why not make this the default - so I supect this is NOT ok which is why it is 5 mins by default, so can I avoid setting CLIENT_READ_TIMEOUT for all 200 clients, just because 1 clients takes longer
   In my opinion you should NOT set the CLIENT_READ_TIMEOUT to values of 40 - 60 mins as this effects all clients and therefore any genuine issues will take much longer to time out and this is why timeout is normally set and should stay set to a relatively small value of 5 - 10 mins.  The work-a-round I implemented was to disable validate of DB (https://www-secure.symantec.com/connect/forums/setting-bpstarttimeout-opscenter#comment-11107841) as this is pointless in the current code as the return status is not checked
    
4. I did not originally ask a 4th question, but in a subsequent post I mentioned the script that ran the database backup to disk and validate ran for all polices, including ones like the O/S which have nothing to do with the DB and this was answered by user sdo:
   You can use a bpstart_notify[.POLICYNAME[.SCHEDULENAME]] script so that the script only runs for a specific policy and/or schedule.

Mike