Have a look at IC35801:
****************************************************************
* USERS AFFECTED: All Tivoli Storage Manager users of *
* versions 4.2 and 5.1. *
****************************************************************
* PROBLEM DESCRIPTION: If a change/update is made to an *
* existing policy for a storage pool *
* and management class used for lanfree *
* backups or archives, the storage *
* agent will not recognize the change *
* after the policy has been reactivated. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The problem was originally written against the documentation
lacking instrcuctions for this problem, however the solution
was to fix the problem in the product code. This situation
will no longer be a problem in a future release.
-----Original Message-----
From: Ted Byrne [mailto:ted.byrne AT ADELPHIA DOT NET]
Sent: maandag 19 januari 2004 19:57
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Does change in copygroup destination require StorageAgent
restart?
We ran into a situation over the weekend that I have not seen mentioned
before, and I was hoping that someone might be able to shed some light on
what occurred.
TSM server has a 3583 library attached to it, connected via SAN. TSM has
been running for almost a year, using LAN-free backups for two DB servers
(cold DB backups, using just the backup-archive client and
StorageAgent). During that time, all backups have been to two LTO-1 drives.
Last week, four LTO-2 drives were added to the library, and the library was
partitioned so that the two original drives are in one library (libr 3583,
devclass 3583). The second partition contains the 4 new LTO-2 drives (libr
3583-2, devclass LTO2)
Access to the new drives was tested from the TSM server, and everything
was working fine. All server-side operations were cut over to use LTO2,
without encountering any problems once the devclass and storagepools were
defined. Testing of the LAN-free backups had do wait for a maintenance
window this past weekend. Once the devices were visible on the systems
with the Storage Agents, the Storage Agents were stopped and
restarted. Messages were logged for both storage agents that the new
library was recognized:
ANR8920I (Session: 12560, Origin: APP1_PROD_STA)
Initialization and recovery has ended for shared library 3583-2.
After the Storage Agents were restarted, the copygroup for the LAN-Free
clients' policy domain was modified to point to the new LTO2 storagepools,
and the policyset was activated. We confirmed that the activation was in
effect by querying the copygroup, and then started a backup on each of the
two clients. In both cases, tapes were mounted to the "old" LTO1 drives.
We went back and double-checked all settings, and all appeared correct, but
tapes from the 3583 devclass (LTO1) were still being mounted in the LTO1
drives.
When we stopped and restarted the Storage Agents on the two clients and
attempted another backup, scratch tapes were mounted into the LTO2 drives,
and the volumes were defined in the intended LTO2 storagepool.
Is there a documented requirement that the storage agent needs to be
restarted after a copygroup destination is changed on the TSM server? I've
searched, and did not find anything, but it's certainly possible that I
overlooked something.
Thanks,
Ted
|
