>I'm at a DR exercise and have discovered that many of the files that we needed >recovered were in an unavailable primary storage pool. What seems to have >happened was that a few weeks prior to the exercise we reorganized into three >storage pools; one with a vaulted copy storage pool for servers that needed to >be recovered, and two that did not have a vaulted copy storage pool for servers >we didn't need to recover offsite. The default management class is in one of >the latter pools. For whatever reason it appears that many critical files are >in the default management class. What I did was to create three sets of client >options, each with an INCLEXCL option to assign all files to the appropriate >management class. The statements all look like "include ?:\...\* >mgmt_class_name" and the sequence number assigned to the option statement is the >highest in the list. I thought that this would 1) be the first include >statement evaluated by the client (it's on the TSM server) and 2) be globally >applied to all files on the client.
It may be that your change was too recent and insufficiently thorough to meed the DR needs... Remember that files are not rebound unless the participate in a backup. The files you needed may be oldies in the original server storage pool. Another foible in stgpool reorganization plans is data-rich directories (e.g., Windows): they are too much to be kept solely in the server db, and so have to be in a stgpool; and the rule is that in the absence of DIRMc, they go with the management class with the longest retention - which some customers have found to be a mongrel MC they had hanging around in their definitions with no expectation that it would ever be used. Richard Sims, BU
