Question of the masses - How long do you keep your volhist?

[paschumacher]

I'd like to ask everyones opinion.

How long are you keeping your volhist for? I am currently keeping ours for 60 days since that is how long the previous TSM admin kept his for. Until I started running short of scratch tapes, I didn't really see a need to change it. At $3000 for a box of 100 LTO3 tapes, its starting to be a cost vs. reward problem. Our SLA for restores is 45 days and we do off-site tapes, but currently do not archive anything. I have 12 TSM servers and on average cut about 25 DB Backup tapes per day.

Thanks and your opinions are greatly appreciated.

 

[rmazzon]

We keep our volhist essentially forever. That does not affect our use of scratch tapes though. Perhaps you are referring to deleting the DBB backup tapes? In our environment we use DRM and those are deleted based on the DRMDBBACKUPEXPIREDAYS value, which for us is 8 days. If not using DRM then you must have an admin sched that performs a del volhist for type=dbb.

The 45 day SLA does not mean you need to keep 45+ days of DBB tapes. The most recent DBB can recover back 45 days/versions assuming your retention allows it.

 

[paschumacher]

thanks for your reply rmazzon.

i was under the impression that a tape could not be returned to the scratch pool if it was contained in a volume history file.

i have a admin schedule that runs every morning:

del volhist todate=today-60 t=a

i wonder if i should setup one that says:

del volhist todate=today-14 t=dbb

 

[dms19]

if you are backing up your devconfig and volhist they should just be local txt files that contain the info for you to reference later (in the event of DR). Deleting the volhist t=dbb -x number of days will delete those tapes from the volhist that are database backups older than "x"

that in turn will free up some tapes here and there.

 

[Jacob_6]

If you are using disaster recovery manager (DRM) it controls the expiration of your db volumes. Using a delete volh to do your db volumes in addition to it, will cause you to lose track of the deleted db volumes that are offsite.

use q drmstatus and look at "DB Backup Series expiration days: 30 Day(s)"


http://publib.boulder.ibm.com/infoc...adminref_aix258.htm#dqx2r_cmd_drmstatus_query

Adjust your db expiration here using set DRMDBBackupexpiredays--days to adjust the number of days you want to keep the db volumes offsite.

http://publib.boulder.ibm.com/infoc...ix367.htm#dqx2r_cmd_drmdbbackupexpiredays_set

 

[rmazzon]

paschumacher:
Be very very careful here. Firstly you DO NOT want to use del volhist ... -t=all under most circumstances. Expiration, reclamation will ensure expired data goes away and scratch tapes are recovered.

Deletinh all tapes from volhist older than 60 days could cause you problems. Depending on how you perform tape ejects/recalls for off-site you could lose track of some of them. There really is no need to do the del volhist unless you are really hard up for disk space on the TSM server to hold the volhist text file.

If you are not using DRM and are off-siting tapes I recommend you start look into it. It will automatically remove DBB entries for example and can greatly simplify the whole tape management chore.

But your initial problem was with using up more than anticipated scratch tapes. You need to look at your reclamation, collocation and retention settings (client occupancy) as well as client backup quantities to determine where your growth lies.

 

[paschumacher]

i am reclaiming data pretty well. most of the problems i have being short on scratch tapes is growth. we have added over 250 VM's in just the last 30 days with alot more coming. couple that with managements lack of understanding that new servers means new backups for TSM, ive got problems. i'm basically trying to stuff a watermelon through a garden hose right now with no relief in sight.

i am using DRM to a copy group and off-siting tapes.

so to make sure i understand this, if i have a tape at the vault longer than 60 days, because it was removed from the volhist file, that tape is considered lost? i probably need to read the DRM section of the TSM guide again.

i thank you all for your input and apologize for my ignorance on this subject. this was something i learned from the previous TSM admin and never thought twice about it.

 

[rmazzon]

No deleting the volhist record does not lose the volume to DRM. But depending on how you create your list of recall tapes some may get overlooked. If all you do is move drm wherestate=... or query drm wherestate=...then you are good. But if you start employing weird selects, like I am forced to do due to complexity here, then references to volhistory will fail and tapes will effectively be orphaned.

Managements ability to selectively understand is always a source of amazement. Tally up the current occupancies and again next week and give them a growth trend and then tell them the max that can fit in the library. If you got past occupancy numbers add those to the chart.

 

[paschumacher]

DB Backup Series Expiration Days: 60 Day(s)
Recovery Plan File Expiration Days: 60 Day(s)

These are my settings for DRMedia above. I'm guessing that is why the volhist was kept for 60 days. This was set by the previous administrator and I guess I have never changed it.

I move tapes from the vault by doing that very process:

move drm * wherest=courierr tost=onsiter
move drm * wherest=vaultr tost=onsiter

Looks like I am doing ok then. Thanks for your input everyone!!

 

[tsmtodd]

Sorry to bring this thread back from the dead.
My DRM DB Backups and Recovery Plan Files are set to 7 and 10 days, respectively (don't ask me why they are different, the logic currently escapes me).
My question is the same, but let me word it differently.
Is there any need to keep volhist entries beyond the date of your oldest active tape?
If my DBBs are getting taken care of via DRM within 7 days, and if my primary and copy storage pool tapes are getting handled by reclamation, expiration and the like, is there any reason to maintain entries in the volhist older than my oldest active storage pool tape?
I have entries in my volhist that go back more than 10 years, and on devclasses that we no longer have (LTO1, LTO2, etc). I can easily determine the age of my oldest tape. It shouldn't hurt anything to delete volumes older than that tape... correct?

Thanks,
Todd