How to set up Avamar and DB2 backup object retention

I was configuring a DB2 LUW database to work with Avamar as the backup system. An issue arose about managing the DB2 database backup retention period. Does DB2 LUW or Avamar control the retention period for a DB2 LUW database?

For some comparison , I’ll outline briefly how TSM is configured with DB2 LUW.

If I set the NUM_DB_BACKUPS, REC_HIS_RETENTN, AUTO_DEL_REC configurations and values in a DB2 database and use TSM , then these values have a direct impact on the TSM retention. In a typical TSM configuration , the usage  AUTO_DEL_REC_OBJ will delete the objects from TSM once the DB2 history file is pruned based on values in NUM_DB_BACKUPS and REC_HIS_RETENTN

Number of database backups to retain   (NUM_DB_BACKUPS) = 12
Recovery history retention (days)     (REC_HIS_RETENTN) = 14
Auto deletion of recovery objects    (AUTO_DEL_REC_OBJ) = ON

 Read more about these parameters at Manage DB2 backups retention policy

These values influence the db2 history file.

In comparison how does Avamar interact with the history file?

The short answer is that pruning of the DB2 history file does not sync up with the Avamar catalogue.  DB2 history pruning effects only the local DB2 history file .   Avamar will expire based on the retention in the Avamar group.

 Let’s look a bit closer at the two scenarios in retention and expiration in the DB2 LUW and Avamar set up.

1) Archive logs and adhoc backup sent from the DB2 client. In this situation typically you’d have the LOGARCHMETH1 configured for the Archival logging management and then use ad-hoc backups. For example , you'd configure LOGARCHMETH1 for archival logging and issue a backup referencing the relevant Avtar libraries:

 db2 update db cfg for MYDB using LOGARCHMETH1 VENDOR:/usr/local/avamar/lib/libdb2_avamar.so logarchopt1 @/usr/local/avamar/avdb2.flg

db2  backup db MYDB online load /usr/local/avamar/lib/libdb2_avamarloader.so  open 2 sessions options @/usr/local/avamar/avdb2.flg

To set the Avamar expiration add      --expires=10  to the flag file.  I’ve used 10 as an example, set it according to the Recovery Point Objective and Backup Retention Policy for this database server.

The key to this configuration is ensuring all the file are available to perform a Restore and Rollforward. Setting the correct expiries is critical.

The other reason to set the expiry is to ensure the backup copy is not kept forever. Avamar doesn’t assign a retention when there is a CLI backup

2) Avamar backups. In this scenario backups are scheduled and managed through Avamar. The retention set at the group level defines the retention period for the backup objects.

A reminder  that pruning of the DB2 history file does not sync up with the Avamar catalogue. DB2 history pruning effects only the local DB2 history file .   Avamar will expire based on the retention in the group.

Ensure the retention period set at the flag file is co-ordinated with the Avamar group retention.So that means that it is necessary to coordinate the retention between the avtar flag set on the database server and Avamar groups very carefully.

This command will list the backup objects stored

../avtar --flagfile=/usr/local/avamar/avdb2.flg --list

Read More on Avtar , Avamar and DB2 backups

 Avamar avtar command option cheat sheet

SQL2161N A damaged recovery history file could not be fixed. (DBA ...

How to terminate a DB2 backup (DBA DB2)