Raghu On Tech

Pro tips on managing data at scale

How To Configure DB2 To Use NetBackup ?

by | Mar 16, 2018 | 0 comments

Task Description:

Configure Db2 LUW database and transactions log backups to use Veritas NetBackup Enterprise backup solution.

 

Task Assumptions:

The task procedure in the next section makes following assumptions. As a result please read below bullet points carefully.

  • You are using RedHat Enterprise Linux family related Operating System.
  • You already installed NetBackup client on the Db2 server that you are planning to configure NetBackup.
  • Installed NetBackup at “/usr/openv/netbackup“.
  • Database name is assumed to be SAMPLE.
  • Your NetBackup Administrator created a NetBackup policies of type Db2 and of names DB2_<APPLICATIONAME>_BACKUPS, DB2_<APPLICATIONNAME>_LOGS
  • Where <APPLICATIONNAME> is the name of your application and an assumption is made that MAXIMA is my application name. So my policy names would become DB2_MAXIMA_BACKUPS and DB2_MAXIMA_LOGS.
  • You already negotiated retention policies for backup and log policies with your NetBackup Administrator.
  • You already requested your NetBackup Admin to add the Db2 server as the client for the NetBackup policies (database and logs).

 

Task Procedure:

Before you can backup your database and transaction logs using Veritas NetBackup solution, you need to perform some configuration with respect to NetBackup and DB2. Therefore, we will see the configuration in the initial part of this procedure.

 

Update NetBackup Configuration File:

Configure /usr/openv/netbackup/bp.conf, below is how my /usr/openv/netbackup/bp.conf file looks. If its not obvious, I modified the hostnames for my netbackup media and master servers. I also modified my Db2 server name.

 

I actually got the above information from my NetBackup administrator. In the above output, the first “SERVER” entry is the NetBackup master server name (both short and long hostnames). Rest of the 9 “SERVER” entries belong to media servers. NetBackup master server is the one that owns the scheduler, have job information, client information, policy information and access to backend database(s) to update any of the job/policy related information.

Where as NetBackup media server(s) are optional that means if your master server have tape drives assigned to it, it can handle everything but that solution is not very scalable. As a result most enterprises create multiple media servers with different types of storage attached to them. Media servers handling active backups usually have high performing storage, corporations might choose to keep last 7 days worth of backups on the high performing storage/disk and then archive them over to a cheaper storage such as tape devices etc. for the rest of their retention policy period. You may find more information about differences between NetBackup master and media servers at “Veritas Open Exchange (VOX)“, for e.g. below thread has some discussion going on

Difference Between NetBackup Master vs Media Server

CLIENT_NAME” parameter in “/usr/openv/netbackup/bp.conf” identifies the server that is being backup. This parameter name might cause some confusion to you but look it at from NetBackup server point of view. For NetBackup server our Db2 server is a client, since our client is using NetBackup server services for backup and restores.

EMMSERVER” parameter identifies the emergency media server, this parameter kicks in when rest of all the media servers go unavailable. In our case its the master server. There could be other parameters that your NetBackup Admin might request you to add to “/usr/openv/netbackup/bp.conf” to tune performance or change other default behaviors of NetBackup clients interaction with the Server.

 

Update Db2 Configuration Files:

There are a few configuration files that you need to update on the Db2 end, for Db2 to be able to talk to NetBackup and vice versa. Even though file db2.conf is not strictly part of the Db2 software, it usually resides in the Db2 instance home directory.

Here is how my db2.conf looks. I will explain each of these entries below.

 

Important: db2.conf file can act really goofy. I mean you can not leave any uncommented non-blank lines. It does not even like lines with spaces, tabs or any other white space characters. If you leave any uncommented non-blank lines your backups may not succeed.

Getting back to db2.conf file entries, there are only two blocks of entries that you should pay attention to. One for Db2 database backups and another one for Db2 transaction log backups. Consider the following block which specifies the policy and schedule for the database backups.


DATABASE SAMPLE
OBJECTTYPE DATABASE
POLICY DB2_MAXIMA_BACKUPS
SCHEDULE Default-Application-Backup
ENDOPER

 

  • Here DATABASE stands for name of the database you are trying to backup.
  • OBJECTTYPE can be either DATABASE for database backup entry or ARCHIVE for transaction log backup entry as you can see in the second entry for Transaction logs.
  • POLICY here stands for name of the Db2 NetBackup policy that is being used by database backups. Remember this policy needs to be created as Db2 type from NetBackup end or your backups will not succeed.
  • SCHEDULE parameter here represents any backup schedule you might have provided to your NetBackup administrator. In our case we did not want NetBackup to trigger our backup jobs, so we left it as default (Default-Application-Backup) i.e. we will run the backup jobs from the Db2 server rather than from NetBackup Master server.

 

Update LOGARCHMETH1 To Use NetBackup Db2 Library:

Updating LOGARCHMETH1 to vendor library lets Db2 backup the archive log files to media server provided an ARCHIVE entry for the database exists in the db2.conf file. Your Db2 library for NetBackup should reside at “/usr/openv/netbackup/bin/nbdb2.so64” by default.

 

Update LOGARCHOPT1 To Allow For Alternate/Cross Node Restores:

You should not need to do this technically, since you already updated db2.conf. However I encountered situations where value in the db2.conf was not picked up for some reason. Updating LOGARCHOPT1 to BKUP_IMAGE_PERM=ANY, lets you perform restore of Log backups taken on one Db2 instance/server to another Db2 instance/server.

Test Database Backup Using NetBackup For Db2 Library:

Your database backup command will slightly change to load NetBackup library for Db2. Lets have a go at it and see what happens.

 

After viewing the backup command above, you are probably wondering what are “LOAD” and “OPTIONS” parameter. First of all let me explain what LOAD option tells Db2. “LOAD /usr/openv/netbackup/bin/nbdb2.so64” tell Db2 where to look for NetBackup library to communicate with the NetBackup server to send its database and log backups to.

Secondly, “OPTIONS BKUP_IMAGE_PERM=ANY” is very important if you intend to restore the backups taken on one machine/instance onto another machine/instance. By default NetBackup assigns read/write permissions to the group and owner of the user running the backup. If a different user or a user not belonging to the group that owns backup file tries to restore the backup you will encounter an error from NetBackup API. Please remember that the error message you might get is not very helpful.

 

Test Transaction Log Backup Using NetBackup For Db2 Library:

You can force an active log to get archived using archive log command as show below and see the log archival status in db2diag.log as shown below.

 

Verify Your Backups:

You should be able to verify that the backup has been completed successfully from both Db2 and NetBackup end. On Db2 end you can use “list history” command. Where as on the NetBackup side you can view the log file under “/usr/openv/netbackup/logs/user_ops/dbext/logs

 

Below are the contents of log file on the NetBackup side. It appears that NetBackup creates a log file for each backup operation i.e. one log file for database backup and a log file every time a transaction log gets archived. You can identify the log file of interest with the backup timestamp. As you can see it is obvious that our Db2 database backup completed successfully.

 

In conclusion, this blog post covers some basic steps you need to perform to configure your Db2 databases on Linux to use Veritas NetBackup for your Db2 backup and restores.

However, there is chance that you may run into issues while configuring NetBackup for Db2. If that is the case you may want to check out below blog post on troubleshooting NetBackup issues with Db2.

Troubleshoot Db2 Backup Failures With Veritas NetBackup

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Shares
Share This

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close