decreasing scratch volumes

[steinbacher]

Hello,

we're running TSM 5.5 with tape library.
I'm quite new with TSM but I've learned to work and configure it quite ok.

Our TSM is configured to throw out at least 2 tapes every day (one DB tape and one with data) which are put into our safe.

scheduled command for this:
move drm * wherestat=mount tostat=vault remove=bulk

every day we are running:
expire inv w=y
ba stg dirpool copypool w=y
ba stg diskpool copypool w=y
ba stg tapepool copypool w=y
migrate stg dirpool lo=0 w=y
migrate stg diskpool lo=0 w=y
migrate stg cdp-restore lo=0 w=y
del volhist t=all todate=today-90
del volhist t=dbb todate=today-8
ba db t=f devcl=lto3 s=y w=y
ba volhist
ba devconf
reclaim stg tapepool thre=70 w=y
reclaim stg copypool thre=60 w=y
audit lic

where tapes are set to vaultretreive.

The problem is following:
there are always to less tapes coming back from vault. Most of the time we are putting daily 2 tapes into safe/vault and get just one back which is getting automatically scratched. This means we have to manually scratch tapes every few days otherwise we are running out of scratch tapes. We need not to scratch 'new' tapes. we have enough tapes in our safe which we can scratch because they aren't in any tapepool any more in out TSM system. But the best would be if we have to put always the same amount of tapes from our safe into the library as we are taking out. But it seems difficult to realise this but I want to automate this completely so that we don't need to scratch in tapes manually ervery few days.

Please can anybody assist me with this problem?

Reinhard

[Samuel]

What is the reuse delay for your stgpool tape ?

q stg stgpool_name :
"Delay Period for Volume Reuse: 0 Day(s)"

[steinbacher]

Hi Samuel,

thanks for your fast reply! The delay is set to

'Delay Period for Volume Reuse: 0 Day(s)'

I think this should be ok?


Reinhard

[cfhoffmann]

....But the best would be if we have to put always the same amount of tapes from our safe into the library as we are taking out.

Reinhard

It might be best, but it's unlikely to happen. Depends on your retention periods. Let's say you are archiving all your data for 1 year. In this case nothing is going to come back from your "safe" until it expires in 365 days.
What management classes/copy groups are you using ?
And are all the commands you listed ('expire inv') actually completing successfully ?

[rmazzon]

There is always going to be a delay when you are moving tapes around. But I noticed that you are using DRM to control this tape movement while also deleting volhistory entries using del volhist. This is taken straight from the help del volhist output

For users of DRM, the database backup expiration should be controlled with the SET DRMDBBACKUPEXPIREDAYS command instead of this DELETE VOLHISTORY command. Using the DELETE VOLHISTORY command removes Tivoli Storage Manager's record of the volume. This can cause volumes to be lost that were managed by the MOVE DRMEDIA command. The recommended way to manage the automatic expiration of DRM database backup volumes is by using the SET DRMDBBACKUPEXPIREDAYS command.

YOu may have some lost volumes (to TSM) sitting in your vault.

[steinbacher]

I don't know exactly what you want to know about our mgmt classes but we have several management classes. We aren't using archive copy groups just backup copy groups E.g. database backups are held like this:

---
Backup Copy Groups : DB ACTIVE MC_DB STANDARD
Policy Domain Name DB
Policy Set Name ACTIVE
Mgmt Class Name MC_DB
Copy Group Name STANDARD
Versions Data Exists 10
Versions Data Deleted 2
Retain Extra Versions 34
Retain Only Version 34
Copy Mode MODIFIED
Copy Serialization SHRSTATIC
Copy Frequency 0 Copy Destination DISKPOOL
Table of Contents (TOC) Destination -
---
File servers like this:
---
Backup Copy Groups : WINDOWS ACTIVE MC_WIN STANDARD
Policy Domain Name WINDOWS
Policy Set Name ACTIVE
Mgmt Class Name MC_WIN
Copy Group Name STANDARD
Versions Data Exists 10
Versions Data Deleted 2
Retain Extra Versions 30
Retain Only Version 365
Copy Mode MODIFIED
Copy Serialization SHRSTATIC
Copy Frequency 0 Copy Destination DISKPOOL
Table of Contents (TOC) Destination -
---

Our expire inv ends after about half an hour with following comments:

08-03-2010 07:48:21 ANR0812I Inventory file expiration process 57 completed:
examined 1724573 objects, deleting 68167 backup objects,
0 archive objects, 0 DB backup volumes, and 0 recovery
plan files. 0 errors were encountered. (SESSION: 4273,
PROCESS: 57)
08-03-2010 07:48:22 ANR0987I Process 57 for EXPIRE INVENTORY running in the
FOREGROUND processed 68167 items with a completion state
of SUCCESS at 07:48:22. (SESSION: 4273, PROCESS: 57)


best regards,

Reinhard

[cfhoffmann]

Retain Only Version 365

means you are retaining your (deleted) file server data for 365 days. In other words it will remain on the tapes in your safe for 365 days before it expires and allows the tapes to becomes scratch. If file servers make up a large proportion of your backups then this could explain your problem (of few tapes coming back from the safe).