drm copy pools not expiring

[amsterdam]

Hi all,

I have a basic TSM (Version 6, Release 2, Level 2.2) setup that's been running in production under RedHat 6 since May. One machine (both server and client), one backup pool, one copy pool. File system backups run nightly and everything can fit on a single LTO5 tape for now. Every two weeks, I run "backup stg backuppool copypool" and "move drmedia tostate=vault" and move the copypool tape off site.

I was under the assumption that when "expire inventory" runs, that this would also expire copy pool volumes as well, but they're still showing up as "Filling" instead of "Empty" or "Pending." I have only one policy with a copy group and no archive group. I initially kept files for 60 days, but after trimming that back to 30 days, copy pool volumes haven't changed. The oldest copy pool volume was last written to on May 12.

Here's some of the details on the policy and drm configuration:

Copy Group Type: Backup
Versions Data Exists: 2
Versions Data Deleted: 1
Retain Extra Versions: 30
Retain Only Version: 30

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

Note: I'm not using DRM for database backups, just file system backups. I also set the reclamation threshold of the copy pool to 75%, but when I try to reclaim, TSM says "still contains files which could not be moved." This happens on the oldest volume which should be expired by now.

I've read the Redbooks and started off with a simple TSM implementation, but I'm obviously missing something. Any pointers are greatly appreciated.

thanks,

Adam

 

[amsterdam]

Nope, no volumes in error state and they're all either "Empty" or "Filling"

 

[amsterdam]

When I run "q drm" everything's in the vault. It was my understanding--and this is where my lack of understanding is probably at fault--that expire inventory would move expired tapes to the vaultretrieve status. So in answer to the second question, no, I don't run the command because I thought it was done during the expire inventory process. The redbook made it sound like all I needed to do was query which drm volumes are in vaultretrieve and pull those back from offsite storage.

 

[amsterdam]

To clarify, nothing is ever going to the VAULTRETRIEVE status, and I can't force a volume to that status. In fact, I can't move any drm volume to any status. I just says: "The specified destination state [x] is invalid"

So as far as I can tell, the VAULTRETRIEVE status gets set by drm somehow, but that's not happening and I don't know to make it happen.

 

[amsterdam]

Thanks, yes, this indeed was the problem. After running reclamation, all the drm volumes that are in VAULT status are PENDING. After the delay period for the volumes reuse on the storage pool has passed, they should be empty and go to vaultretrieve.

Thanks again for the help!