ExpireDBBackupDays vs Del Volhist

[ILCattivo]

I am fairly new to the realms of DRM and have previously used the del volhist type=dbs cmd to remove older TSM db backups.

Now I have inherited a few TSM Servers running DRM (7.1.5) and have found both the ExpireDBbackupdays setting and del volhist type=db? applied. IBM do not recommend both to be used at the same time and I have seen this first hand recently when Tape volumes disappear off the radar. So, I wanted to gauge how best to configure a TSM server where the following DB backups are taking place under a DRM environment.

backup db type=dbs devcl=<FileClass>

backup db type=FULL devcl=<LTOClass>

q drmstat...

DB backup Series Expiration days: 3

Now, I understand that DRM should take care of those db backups sent to a Tape file Class. (no probs there) So how does one manage the dbs ones sent to tape without using the 'del volhist type=dbs' cmd, which if set incorrectly can remove volume history from the DB?

Thanks

 

[inthesun]

Hi,

The DRMDBBACKUPEXPIREDAYS option allows expiration to remove the volumes for you.

The value set by this command applies to both a snapshot and a full plus incremental database backup series. Any type of database backup series is eligible for expiration if all of the following are true:

• The age of the last volume of the series exceeds the expiration value set with the SET DRMDBBACKUPEXPIREDAYS command and the value that is specified for the DELgraceperiod parameter in the DEFINE SERVER command. The DELgraceperiod parameter applies only to remote database backups. The default value for the DELgraceperiod parameter is 5 days. For example, if you set the value for the SET DRMDBBACKUPEXPIREDAYS command to 7 days and set the value for the DELgraceperiod parameter to 6 days, the remote database backup series does not expire until 13 days elapse.
• For volumes that are not virtual volumes, all volumes in the series are in the VAULT state.
• The volume is not part of the most recent database backup series.

Remember: The most recent backup series of either type is not deleted.

Key is that this option is just for DRM volumes that have been moved from Mountable to DRM state of VAULT.

So, for none DRM DB backups, you would still need to do the Delete Volhistory command.
www.ibm.com/support/knowledgecenter/en/SSGSG7_7.1.7/srv.reference/r_cmd_volhistory_delete.html

 

[ILCattivo]

Hi inthesun,

Many thanks for this very useful information.

So just to clarify, the DRMBACKUPEXPIREDAYS setting applies to both 'dbb' & 'dbs' backups regardless of whether they reside on FILE, DISK or LTO dev classes?

For example...
If DRMBACKUPEXPIREDAYS = 2 days, should I expect to see no more than the most recent 2 x dbs backup files located on my db backup file dev class location on any one day?

Thanks

 

[erwanns]

Hi,

DRMDBBACKUPEXPIREDAYS only applies to all DB backups that are in the VAULT or REMOTE state, whether they are DBB or DBS.

DRM does not processes FILE volumes by default, because it's not easy to export them to a vault compared to TAPE volumes.

DBS should be prefered to DBB for DRM usage.

 

[ILCattivo]

Excellent explanations and I now understand the processes involved with db backup management and it's relation with DRM.

Many thanks inthesun & erwanns for taking the time to reply to my query.

 

[ILCattivo]

Thought i'd come back to this thread with this similar related db backup /drm query..

Below is a list of DBSnapshots taken daily to LTO Media.
I have pulled this info out of the volumehistory

24/01/2017 08:31 A00030L4 DBSNAPSHOT LTO_DEV1 16 0 100001 VAULT
25/01/2017 08:15 A00039L4 DBSNAPSHOT LTO_DEV1 17 0 100001 VAULT
26/01/2017 10:13 A00056L4 DBSNAPSHOT LTO_DEV1 18 0 100001 VAULT
27/01/2017 11:26 A00065L4 DBSNAPSHOT LTO_DEV1 19 0 100001 VAULT
28/01/2017 10:23 A00066L4 DBSNAPSHOT LTO_DEV1 20 0 100001 VAULT
29/01/2017 09:54 A00072L4 DBSNAPSHOT LTO_DEV1 21 0 100001 VAULT
30/01/2017 07:51 A00074L4 DBSNAPSHOT LTO_DEV1 22 0 100001 VAULT
31/01/2017 08:29 A00026L4 DBSNAPSHOT LTO_DEV1 23 0 100001 VAULT
01/02/2017 11:55 A00054L4 DBSNAPSHOT LTO_DEV1 24 0 100001 VAULT
02/02/2017 10:02 A00077L4 DBSNAPSHOT LTO_DEV1 25 0 100001 VAULT
03/02/2017 10:42 A00013L4 DBSNAPSHOT LTO_DEV1 26 0 100001 VAULT
04/02/2017 10:06 A00051L4 DBSNAPSHOT LTO_DEV1 27 0 100001 VAULT
05/02/2017 10:11 A00079L4 DBSNAPSHOT LTO_DEV1 28 0 100001 VAULT
07/02/2017 12:00 A00040L4 DBSNAPSHOT LTO_DEV1 29 0 100001 VAULT
08/02/2017 10:27 A00058L4 DBSNAPSHOT LTO_DEV1 30 0 100001 VAULT
09/02/2017 09:58 A00063L4 DBSNAPSHOT LTO_DEV1 31 0 100001 VAULT
10/02/2017 11:26 A00073L4 DBSNAPSHOT LTO_DEV1 32 0 100001 VAULT
14/02/2017 19:25 A00057L4 DBSNAPSHOT LTO_DEV1 33 0 100001 VAULT

- The DRM DBBackupSeriesExpireDays setting is [3days]
- Expiration has been running daily without failure.
- The volumes do not appear when running a >q drm

Q1: Why are these volumes not expiring after 3 days?
Q2: How can I get these volumes back to use as scratch again ASAP?
Q3: Why do they not list in drm?

Many Thanks

 

[inthesun]

Hi,

The correct option name is: DRMDBBACKUPEXPIREDAYS, so you may want to verify it is set correctly. The only APAR, I was able to find, for this option was closed back in 2002. See this link:
www.ibm.com/support/docview.wss?uid=swg1IC34037
The last documantion APAR was closed in 2007:
www.ibm.com/support/docview.wss?uid=swg1IC53563

From your last question, it sounds like DRM is not processing the volumes at this time.

This document has steps to specifically verify and then expire just the DRM volumes:
www.ibm.com/support/docview.wss?uid=swg21584678

If the above does not expire the correctly set DRMDBBACKUPEXPIREDAYS, then do the step 2 (not step 1) at this document:
www.ibm.com/support/docview.wss?uid=swg21600211

If there is still a problem, this link has an overview of the DRM steps:
www.ibm.com/support/docview.wss?uid=swg21106965

If your system is not working, then you may want to look to see if your level of server is at a supported level. If not a V6.3, V7.1 or V8.1 server, then you may want to upgrade to the latest fix level and test again. If still failing, then I would recommend calling support.