bpstart_notify.bat does not run as at all on my clients (windows)

[el_grom]

Hi all,

I run into an issue with the usage of bpstart_notify script. I read a lot of similar post on the forum but didn't found the solution.

Here is my situation and what I've done:

1. Create a simple batch file located in "C:\Program Files\Veritas\NetBackup\bin\bpstart_notify.bat"
2. Just to see its behavior, I set this as content: "echo test >> c:\test.txt"
3. To test it, I double-click on it. Script is executed and the file is created. I deleted it right after to get back to a normal situation
4. I launch a backup of one of my SQL Server (2012) databases from the "NetBackup MS SQL Client"
5. Backup is correctly done but my "test.txt" file is not created

I read that these scripts are launch by "bpbkar32.exe" but I don't think this process is involved in my scenario. Nothing else was helpfull in the admin guide (or may be I missed something). Do I need to active something on the master server or anywhere else? Nothing else than in my scenario was done.

As general information:

• SQL Server 2012 databases
• NetBackup client 7.5 (will be 7.6 soon)
• Windows Server 2008R2

Thanks for your help!

[Marianne]

It needs to a .bat file, not .cmd:

1. Create a simple batch file located in "C:\Program Files\Veritas\NetBackup\bin\bpstart_notify.cmd"

Rename to bpstart_notify.bat, then create bpbkar log folder on the client under C:\Program Files\Veritas\NetBackup\logs\ before running the backup again.

bpbkar log will show when and if bpstart_notify is called.
You may need to increase logging on client. Level 3 should be fine.

***EDIT ***

notify scripts are only called for MS-Windows and Standard policy types.
It will not be called for SQL policy type.
Please verify that your policy is correct type.

[el_grom]

Hi Marianne, thanks for your reply.

Indeed, it was already a ".bat" file. I don't know why I wrote ".cmd" when I created this post; I edited the original post

If I understand you correctly, there is no way to run scripts like this with a SQL policy type?

[Marianne · Accepted solution]

No way to run it with SQL backups.

As per the documentation that you found, bpbkar calls the start and end notify script.

bpbkar does not run for an agent type policy. Native db backup commands run to backup the database and the plugin sends the data to NBU.

bpbkar only runs for file-level backups. For Windows clients, that will be a MS-Windows policy.

As a matter of interest - why would you need notify scripts for agent backups?

[el_grom]

Thanks for the complete answer!

I'll try to summarize it:

1. Day0: I have a database with 3 datafiles. A backup follows
2. Day1: I remove 1 datafile. A backup follows
3. Day2: I need to restore a copy of the database at time "Day0".

Operation 3 is impossible because NetBackup tries to restore the image (structure with 3 datafiles) with the actual design (structure with 2 datafiles). And I can't modify the bch script without knowing the logical name of each datafile (http://www.symantec.com/business/support/index?page=content&id=TECH19198)

To solve this, Symantec give 2 workarounds:

1. Know the old structure and modify the bch script accordingly
2. Restore the database in another SQL instance, retrieve the old structure then re-restore as copy on the target instance with old structure

In my situation, workaround 1 is not always possible because database structure can change at any time (partitionning and other processes like that are not in my hands). Workaround 2 is not possible at all for security reasons.

My solution was: When a backup is started, "bpstart_notify" script will start a stored procedure in the SQL instance which save the current structure (logical datafile name ...) with the current timestamp. This would allow me to keep an historic of the database structure.

I can't launch this script at the expected start time of the backup because it may happen that a database will change its structure between the start and the end of the complete backup job (the backup job takes 8 hours). Unfortunately, Murphy's laws are always there...