It was inevitable - I've got more tapes and data than I can keep 'hot' in my current library. Paul's question about "TSM admin processes" seems like a nice lead-in to this conversation:
Any best practices for using overflow/MountableNotInLib conditions? I've read the 'Managing a Full Library" page in the Admin guide, but it seems like there are lots of dependencies that make 'move media' commands need some thought. I'm not as worried about restores, as those are manual and observed anyway. I'm more concerned about the basic, automatic storage pool operations and what overflow means to my overall maintenance, and its impacts (for example, reclaims not running as well or using more tapes). Here's my core dump of thoughts and questions; maybe we can get a good discussion here. If I missed a redbook or white paper, please point it out. The days=X flag on the "q media" and "move media" seems handy. I can say "only move tapes that haven't been written to in 28 days" or something. That means I should make sure I've done a 'backup stg' of those tapes in the last 28 days so that they aren't needed for the 'backup stg' command. Because I'm tight on library space, I keep my reclaimation values pretty high on the stgpool I'm migrating. What happens when a MountableNotInLib volume is eligible for reclaimation? Does anything tell me, or do I need to be monitoring the logs for failed reclaims or the volumes for ones that should be reclaimable but aren't. I'm guessing I need a cleanup process somewhere that finds MountableNotinLib volumes below the threshhold and reminds me to move them back to the library. What about reclaimations of copypool volumes that source MountableNotInLib volumes? I'm guessing my copypool tapes reclaims will fail (so I need to watch for that?) or I need to watch for those tapes sticking below their reclaim threshhold as well? Is this going to be a common problem, or is the nature of copies of cold data also stay pretty cold going to keep the copypool reclaims close to the stgpool reclaim frequencies? (As I hinted, I've been tight on library slots for a while, so these stgpools are colloc=no, which probably works against me here.) 'move drm' and 'move media' are independent from each other. Got it. Too bad -- a VaultRetrieve state for 'move media' would be nice, based on how its needed. Or is this the type of thing that ServerGraph helps identify/manage/visualize? I'm also thinking about active pools, although because it's "yet another copy" scenario, that might cause even more library slot contention. Thoughts? Dave -- David Mussulman [email protected] SysAdmin, NetAdmin for the Technology Services Group 2330 Siebel Center Department of Computer Science office: 217.333.6231 -- See https://agora.cs.uiuc.edu for CS Intranet and TSG support info --
