Significance of STGNEW,STGDELETE,STGREUSE volume history entries

[anandgmenon]

Hi Team

Our environment uses TSM6.2 Server.

Can anyone explain the significance of STGNEW,STGDELETE,STGREUSE in volume history. Is it still relevant in TSM 6.2 ???

We backup Database every day and just before the database backup, We use the following script "delvolh" daily to clear out the Volume history entries

Name Line Command
Number
---------- ------ ------------------------------------------------------------
DELVOLH 5 del volh tod=today t=DBS
10 del volh tod=today t=STGN
15 del volh tod=today t=STGR
20 del volh tod=today t=STGD
25 del volh tod=today t=DBB

The script is run in the follwing order

1 ba stg disk offsite w=y
5 ba stg onsite offsite w=y
10 ru delvolh ( Volume history deletion script )
15 ba db dev=lto5 t=dbs w=y
20 ru delvolh ( Volume history deletion script )
25 ba db dev=lto5 t=f w=y
30 ru delvolh ( Volume history deletion script )
35 ba volh filename=/home/pzatsm/recoverydir/volhist.out
40 ba devconf filename=/home/pzatsm/recoverydir/devconf.out

Please confirm if this is ok ???

[moon-buddy]

Do you use DRM? If you use DRM, you should not be using DEL VOLHIST.

STGNEW - new volume added to a stgpool
STGDELETE - deleted volume from a stgpool
STGREUSE - scratch tapes


They are all relevant in TSM even for 6.2

Your script looks fine but 'del volhist' removed IF you use DRM.

[sjl]

I'd amend moon-buddy's comments slightly. DEL VOLHIST on STGNEW, STGDELETE, and STGREUSE is not unreasonable (in my opinion, in the general case), but on DB backups, it certainly is a bad thing if you use DRM; I would be using DRM to manage the cycling of database backup tapes, rather than relying on volume history manipulations.

Why? Simply put: tape leaks. If you do a DEL VOLHIST TYPE=DBB, it circumvents the normal DRM expiration process, and forcibly removes all record of the database backup(s) in question. Unless you have other ways to track DR volumes, that means that you lose track of those tapes. Extremely dodgy.

[anandgmenon]

Hi Moon-buddy,

We use DRM..

We run the script everyday in Production after all the backups and move the copy tapes to DR Site nearby

We do a DR restore on the same day on a daily basis.

Hope this is fine. Please confirm.

[sjl]

Hi Moon-buddy,

We use DRM..

Then I would ditch - completely - the line that says "del volh tod=today t=DBB", and amend the other del volh commands to keep at least a few days - a month, perhaps, or even two - worth of volume history. The DBS history entries should also not be deleted. Use the MOVE DRM command to manage the offsite tapes instead, and look into the DB expiration option in the DRM options (QUERY DRMSTATUS will tell you what it's set to, and the help for that command will give you other relevant commands; sorry, I'm not in front of TSM right now.)

[anandgmenon]

Hi Sjl,

Every day in DR we do a point in time restore of the latest TSM DB and then proceed with the DR Client restores.

This ensures that DR and Production are having the same data backup.

I hope this is perfect. . Is it not ???

[moon-buddy]

Hi Sjl,

Every day in DR we do a point in time restore of the latest TSM DB and then proceed with the DR Client restores.

This ensures that DR and Production are having the same data backup.

I hope this is perfect. . Is it not ???

As mentioned - get away from del volhist for the DB volumes -

What a tedious way of syncing your systems. There are more effecient and less tedious ways of doing this.