CopyPool DRM volume dissappears

[tjelf]

Brand new server (5.4.0) and I have a curious issue on my first DRM rotation.

I have 6 lto tape vols returning from offsite; 5 dbbackups and 1 copypool. Yesterday morning, they were all in a Vault Retrieve status when I ran the email script to inform my offsite storage vendor to return them, which they did, correctly, this afternoon. However, now the 5 dbbackup volumes are still in VR status, as they should be, waiting for me to move them to onsiteretrieve and then check them into the lto library's scratch pool. The Copypool volume is now nowhere to be found in TSM, when it should still be in a VR status.

Am I missing something? This is not what happened on my old 5.1.8 server. I know that I can just label it again the the scratch pool, but to me, it isn't right. I do not want this to happen every week.

Any help would be appreciated. Thanks

 

[heada]

Was the volume "moved" from VR to OR(Onsite Retreive) or CR (Currier Retreive) What does the volhist say happened to the volume?

Regardless, you shouldn't have to label the volume, just check it in as scratch.

-Aaron

 

[tjelf]

The volume was not moved, so it should still be in VR status, as far as I'm concerned. There is no reference to this volume when I query volhist going back 14 days. Nor is there any reference the the other 5 volumes. I have checked the others into the library as scratch volumes. Shouldn't here be entries indicating the the volumes were deleted?

 

[heada]

If the volumes went from VR to OR or CR then you should have a STGDEL entry in the volhist. Rather than running the q volhist query, can you open the actualy volhist file and look through it? It should be listed in date order and everything is date-time stamped as well.

-Aaron

 

[tjelf]

Here is the volhist.out file in its entirety. Something's fishy.

*********************************************************************************************************
*
* Sequential Volume Usage History
* Updated 06/08/2007 13:30:56
*
* Operation Volume Backup Backup Volume Device Volume
* Date/Time Type Series Oper. Seq Class Name Name
*********************************************************************************************************
* Location for volume A00000L3 is: 'IRON MOUNTAIN'
2007/05/29 15:28:30 BACKUPFULL 1 0 1 LTO "A00000L3"
* Location for volume A00001L3 is: 'IRON MOUNTAIN'
2007/05/30 21:42:29 BACKUPINCR 1 1 1 LTO "A00001L3"
* Location for volume A00002L3 is: 'IRON MOUNTAIN'
2007/05/31 01:04:11 BACKUPINCR 1 2 1 LTO "A00002L3"
2007/05/31 01:30:48 STGNEW 0 0 0 LTO "A00003L3"
* Location for volume A00004L3 is: 'IRON MOUNTAIN'
2007/05/31 08:00:20 BACKUPFULL 2 0 1 LTO "A00004L3"
2007/05/31 11:30:47 STGNEW 0 0 0 LTO "A00005L3"
2007/05/31 11:31:05 STGNEW 0 0 0 LTO "A00006L3"
2007/05/31 12:00:02 STGNEW 0 0 0 LTO "A00007L3"
2007/05/31 12:07:35 STGNEW 0 0 0 LTO "A00008L3"
2007/05/31 12:12:04 STGNEW 0 0 0 LTO "A00009L3"
2007/05/31 12:16:24 STGNEW 0 0 0 LTO "A00010L3"
* Location for volume A00011L3 is: 'IRON MOUNTAIN'
2007/06/01 00:31:17 BACKUPINCR 2 1 1 LTO "A00011L3"
2007/06/02 01:30:45 STGNEW 0 0 0 LTO "A00013L3"
2007/06/04 11:31:07 STGNEW 0 0 0 LTO "A00016L3"
2007/06/05 11:31:03 STGNEW 0 0 0 LTO "A00018L3"
2007/06/05 12:36:36 STGNEW 0 0 0 LTO "A00019L3"
2007/06/05 12:38:42 STGNEW 0 0 0 LTO "A00020L3"
* Location for volume A00021L3 is: 'IRON MOUNTAIN'
2007/06/06 08:00:31 BACKUPFULL 7 0 1 LTO "A00021L3"
2007/06/06 12:34:36 STGNEW 0 0 0 LTO "A00022L3"
2007/06/07 03:23:15 STGNEW 0 0 0 LTO "A00023L3"
* Location for volume A00024L3 is: 'IRON MOUNTAIN'
2007/06/07 08:00:31 BACKUPFULL 8 0 1 LTO "A00024L3"
2007/06/07 12:40:41 STGNEW 0 0 0 LTO "A00025L3"
* Location for volume A00014L3 is: 'IRON MOUNTAIN'
2007/06/08 08:00:30 BACKUPFULL 9 0 1 LTO "A00014L3"
2007/06/08 13:30:56 STGNEW 0 0 0 LTO "A00015L3"

 

[nezih]

check your admin schedules for "del volh todate=today-x t=dbb (or all)" you cannot delete old database backups from volhist with this command if you use drm... this makes your drm tapes disappear

 

[heada]

It looks like you have a del volhist running somewhere. As said, this is very bad when using DRM as it will cause tapes to disappear. Check your actlog for the del volhist to confirm.

-Aaron

 

[tjelf]

Unfortunately, the actlog was being pruned every night (now set to 14 days), so I can't currently see whether any del volhist commands were being made.

Review of all my admin schedules reveals nothing that directly refers to volume history deletions. Is there any setting in tsm relative to volume history that would cause the history to be deleted?

 

[nezih]

no, there is no setting for volume history deletion, it's only works via command, but if it's not in the admin schedules maybe there will be a maintenance script on server scripts?

 

[tjelf]

Didn't think so.

I have no maintenance scripts set up, I run those sorts of tasks through administrative schedules.

Would it be possible for the drm "prepare" command to perform any volhist deletions? How 'bout the "expire inventory" routine? Clearly I'm grasping at straws...

 

[heada]

The only process that should remove info from the volhist file is a del volhist command.

Since you have updated the actlog retention, have you looked in the actlog to see if you're running any commands (del volhist) that you don't know about?

-Aaron