Never any data to process from primary tape pool

mi-court-buadmin

ADSM.ORG Member
Joined
Jul 11, 2008
Messages
33
Reaction score
0
Points
0
Location
Lansing, Moooochigan
I get "No data to process for TAPEPOOL01" every day during daily maintenance. Quick synopsis of config:

Backups go to primary storage pool DISKPOOL01 Next storage pool is TAPEPOOL01

High migration threshold set at 90, low mig 70.

Daily
ba stg DISKPOOL01 COPYPOOL01
ba stg TAPEPOOL01 COPYPOOL01

I see in daily reports the disk pool utilization climb though the 60's, 70's, 80's and am not concerned that when the ba stgpool commands run there is no data to process for TAPEPOOL01. Likewise when reclaim runs there is no data to process for TAPEPOOL01. But when I see the disk pool utilization drop one morning, I assume some migration has taken place from DISKPOOL01 to TAPEPOL01. So I would expect to see some data to process for TAPEPOOL01 the next day when ba stgpool commands run, and when reclaim commands run.

It's occurred to me (just now) that if data was copied to the COPYPOOL01 when it resided in disk, then it would not need to be backed up again when it migrated to tape, as it's not new data, just moving data. But I'm a little concerned that there is still no data to process during reclaim. For some reason TAPEPOOL01 has 21 tapes in use, and COPYPOOL01 (off-site volumes) has 35. Tape fill levels appear similar, and we do not have any archive policies active so all the data is backup data.

Am I just being paraniod? I've seen postings here to the effect that Tivoli is very trustworthy, but I get nervous when my carreer is on the line if we lose something...:confused:
 
do you check the content of your tape volumes with "q content volume_name", and see if the data is really there?

Your system looks correct, maybe a restore test would give you some assurance :)

About having no data to process for reclamations, maybe your Tapepool has a very high Reclamation Treshold.
 
Thanks for the quick response.

I did a math check on the sizes of the pools:

TAPEPOOL01 14.3TB 63.8% utilized = 9.1TB
DISKPOOL 1.4TB 72.5% utilized = 1.0TB
______

10.1TB

COPYPOOL01 24TB 42% utilized = 10.1TB

So I think these are fine, it just bothered me that the tape counts were so different. As for reclaimation, the thresholds are the same for both tape pools, but it also occurs to me that when data migrates from disk to tape, all the TAPEPOOL01 volumes are available so it can place files effeciently (I use group colocation with six groups). But by definition most of the COPYPOOL01 volumes are offsite so there must be a whole lot more gyrations to go through to reclaim the volumes that aren't present (by making new ones to replace them and waiting for the old ones to come back).

I've run the q content before, but we have gazillions of files under a 10-year retention policy and it's really painful to look at. :eek: It does tell me there's stuff on the tapes, and the total pool bytes do seem to match up, so I think this is probably OK.
 
Oh, and we test restore almost every day (stupid users!) ;) so we know there is data in the on-site pools. I was most concerned that it was getting to the copy pool, which is harder to verify.
 
Back
Top