Veritas NetBackup™ for DB2 Administrator's Guide
- Introduction to NetBackup for DB2
- Installing NetBackup for DB2
- Verifying the operating system and platform compatibility
- About log archiving
- Configuring NetBackup for DB2
- About configuring a backup policy for DB2
- About adding backup selections to a DB2 policy
- About backing up archive log files with the user exit program
- Configuring the run-time environment
- Creating a db2.conf file for use with the user exit program
- Creating a db2.conf file (vendor method)
- Configuring bp.conf files in a cluster environment
- About NetBackup for DB2 templates and shell scripts
- Creating DB2 scripts manually
- Performing backups and restores of DB2
- About user-directed backups
- Performing a database restore
- Using the NetBackup for DB2 recovery wizard
- Using DB2 to perform a restore
- About an alternate restore
- Using Snapshot Client with NetBackup for DB2
- About NetBackup for DB2 with Snapshot Client operations
- Restoring NetBackup for DB2 from a snapshot backup
- About configuring NetBackup for DB2 block-level incremental backups on UNIX
- Configuring policies for BLI backups with NetBackup for DB2
- About Snapshot Client effects
- Troubleshooting NetBackup for DB2
- About the NetBackup for DB2 log files
- Appendix A. Configuration for a DB2 EEE (DPF) environment
- Appendix B. Using NetBackup for DB2 with SAP®
- Appendix C. Register authorized locations
Registering authorized locations used by a NetBackup database script-based policy
During a backup, NetBackup checks for scripts in the default script location and any authorized locations. The default, authorized script location for UNIX is
usr/openv/netbackup/ext/db_ext and for Windows is
install_path\netbackup\dbext. If the script is not in the default script location or an authorized location, the policy job fails. You can move any script into the default script location or any additional authorized location and NetBackup recognizes the scripts. You need to update the policy with the script location if it has changed. An authorized location can be a directory and NetBackup recognizes any script within that directory. An authorized location can also be a full path to a script if an entire directory does need to be authorized.
If the default script location does not work for your environment, use the following procedure to enter one or more authorized locations for your scripts. Use nbsetconfig to enter an authorized location where the scripts reside. You can also use bpsetconfig, however this command is only available on the master or the media server.
One recommendation is that scripts should not be world-writable. NetBackup does not allow scripts to run from network or remote locations. All scripts must be stored and run locally. Any script that is created and saved in the NetBackup
db_ext (UNIX) or
dbext (Windows) location needs to be protected during a NetBackup uninstall.
For more information about registering authorized locations and scripts, review the knowledge base article:
To add an authorized location
- Open a command prompt on the client.
- Use nbsetconfig to enter values for an authorized location. The client privileged user must run these commands.
The following examples are for paths you may configure for the Oracle agent. Use the path that is appropriate for your agent.
[root@client26 bin]# ./nbsetconfig nbsetconfig>DB_SCRIPT_PATH = /Oracle/scripts nbsetconfig>DB_SCRIPT_PATH = /db/Oracle/scripts/full_backup.sh nbsetconfig> <ctrl-D>
C:\Program Files\Veritas\NetBackup\bin>nbsetconfig nbsetconfig> DB_SCRIPT_PATH=c:\db_scripts nbsetconfig> DB_SCRIPT_PATH=e:\oracle\fullbackup\full_rman.sh nbsetconfig> <ctrl-Z>
Review the NetBackup Command Reference Guide for options, such as reading from a text file and remotely setting clients from a NetBackup server using bpsetconfig. If you have a text file with the script location or authorized locations listed, nbsetconfig or bpsetconfig can read from that text file. An entry of DB_SCRIPT_PATH=none does not allow any script to execute on a client. The none entry is useful if an administrator wants to completely lock down a server from executing scripts.
- (Conditional) Perform these steps on any clustered database or agent node that can perform the backup.
- (Conditional) Update any policy if the script location was changed to the default or authorized location.