Binding a node to a different management class
Technote (FAQ)
Question What is the effect of binding a node to a different
management class?
Answer The management class is the only mechanism that the TSM
server uses to determine when to delete old unneeded client files.
For example a management class contains the backup copygroup
parameters: VerExists, VerDeleted, RetExtra and RetOnly, these
parameters are used by the TSM server to determine when to delete a
file from the TSM storage pools.
For details on file versioning/retention/expiration, please
review the TechNote "File Versioning, File Retention and File
Expiration Explained ":
http://www-01.ibm.com/support/docview.wss?rs=0&dc=DB500&q1=1224145&uid=swg21224145&loc=en_US&cs=utf-8&cc=us&lang=en
A TSM client node could be re bound to a different management
class, however, the following guide lines must be considered:
note: in the following two scenarios the following is
assumed:
Original domain name DOM1
Original management class the node was bound to: MNGT1
New domain name: DOM2
New management class MNGT2
Scenario #1: Binding a node to a new management class under a
new domain DOM2:
If a new management class, MNGT2, is created under the new
domain, all new backups will be bound to MNGT2, but the old data
which were bound to a management class MNGT1, which doesn't exist
under the new domain DOM2, will be automatically bound to the
default management class of the new
Document information Tivoli Storage Manager Extended Edition
Software version:
Version Independent
Operating system(s):
AIX, Linux, Solaris, Windows
Software edition:
Edition Independent
Reference #:
1417815
Modified date:
2010-01-18
Page 1 of 2IBM Binding a node to a different management class -
United States
31/03/2011http://www-01.ibm.com/support/docview.wss?rs=&context=SW000&q1=%2btec...
domain DOM2. The default management class under DOM2 may still
has the default values for file retention and versioning, which may
not be the desired values, and may cause data to be expired
unexpectedly with the next client backup.
To avoid this situation, use one of the following two
options:
+ Modify the default management class under DOM2 with the
desired values for VerExists, VerDeleted, RetExtra and RetOnly
OR
+ Create a new management class under DOM2 named MNGT1, with the
desired values for VerExists, VerDeleted, RetExtra and RetOnly
Scenario #2: Binding a node to a new management class under the
same domain DOM1:
If the old management class MNGT1 still exist, then old data
will continue to be bound to it, but new data will be bound to the
new management class MNGT2. If MNGT1 is deleted, then the old data
will be bound to the default management class under DOM1, which may
still has the default values for file retention and versioning,
which may not be the desired values, and may cause data to be
expired unexpectedly with the next client backup.
To avoid this situation:
+ Modify the default management class under DOM1 with the
desired values for VerExists, VerDeleted, RetExtra and RetOnly
+ If modifying the default management class is not possible,
then create a new Domain and follow the guide lines as in Scenario
#1
Copyright and trademark information IBM, the IBM logo and
ibm.com are trademarks of International Business Machines Corp.,
registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at
"Copyright and trademark information" at
www.ibm.com/legal/copytrade.shtml.
Page 2 of 2IBM Binding a node to a different management class -
United States
31/03/2011http://www-01.ibm.com/support/docview.wss?rs=&context=SW000&q1=%2btec...
