In Tivoli Storage Manager, to take the client files backup each client should be assigned to a domain. Each domain should have one active policy set and any number of inactive policy sets. Each policy set should have one default management class to ensure the client files are managed in server storage if there is no other management class is defined. A single policy can have multiple management classes but one of them should be default. You need to understand the TSM Policy Management concept before trying to understand this. You can define a management class as default by using this below command
assign defmgmtclass <domainname> <policyname> <mgmtclassname>
To understand the purpose of management binding and rebinding, first lets see why we assign a management class as default management class.
Why we should assign default Management Classes
Each policy set must include a default management class. The default management class is used for the following purposes
- To manage files that are not bound to a specific management class, as defined by the INCLUDE option in the include-exclude list.
- To manage existing backup versions when an administrator deletes a management class or a backup copy group from the server.
- To manage existing archive copies when an administrator deletes a management class or an archive copy group from the server. The server does not rebind archive copies, but does use the archive copy group (if one exists) in the default management class.
- Meet the needs of most users
- Contain both a backup copy group and an archive copy group
- Set serialization static or shared static to ensure the integrity of backed up and archived files
- Retain backup versions and archive copies for a sufficient amount of time
- Retain directories for at least as long as any files are associated with the directory
- Other management classes can contain copy groups tailored either for the needs of special sets of users or for the needs of most users under special circumstances.
What is Management Class Binding
- For backing up a file, a client can specify a management class in the client's include-exclude list (include-exclude options file for UNIX and Linux clients), or can accept the default management class.
- For backing up directories, the client can specify a management class by using the DIRMC option in the client options file.
- It is recommended that you define a default management class. If no management class is specified for a directory, the server chooses the management class with the longest retention period in the backup copy group (retention period for the only backup version).
During archiving a file, the client can do one of the following
- Specify a management class in the client's include-exclude list (with either an include option or an include.archive option)
- Specify a management class with the ARCHMC option on the archive command
- Accept the default management class
- It is recommended that you define a default management class. If the client does not specify any archiving options, the server assigns the default management class to the archived directory. If the default management class has no archive copy group, the server assigns the management class that currently has the archive copy group with the shortest retention time.
- For migrating a file, a client can specify a management class in the client's include-exclude options file, or can accept the default management class.
The default management class is the management class identified as the default in the active policy set. A management class specified with a simple include option can apply to one or more processes on the client. More specific include options (such as include.archive) allow the user to specify different management classes. Some examples of how this works
- If a client backs up, archives, and migrates a file to the same server, and uses only a single include option, the management class specified for the file applies to all three operations (backup, archive, and migrate).
- If a client backs up and archives a file to one server, and migrates the file to a different server, the client can specify one management class for the file for backup and archive operations, and a different management class for migrating.
- Clients at Version 4.2 or later can specify a management class for archiving that is different from the management class for backup.
What is Management Class Rebinding
A file remains bound to a management class even if the attributes of the management class or its copy groups change. The following scenario illustrates this process
- A file named REPORT.TXT is bound to the default management class that contains a backup copy group specifying that up to three backup versions can be retained in server storage.
- During the next week, three backup versions of REPORT.TXT are stored in server storage. The active and two inactive backup versions are bound to the default management class.
- The administrator assigns a new default management class that contains a backup copy group specifying only up to two backup versions.
- The administrator then activates the policy set, and the new default management class takes effect.
- REPORT.TXT is backed up again, bringing the number of versions to four. The server determines that according to the new backup copy group only two versions are to be retained. Therefore, the server marks the two oldest versions for deletion (expired).
- Expiration processing occurs REPORT.TXT is still bound to the default management class, which now includes new retention criteria. Therefore, the two versions marked for deletion are purged, and one active and one inactive backup version remain in storage.
Management Class Rebinding is the process of associating a file or a logical volume image with a new management class. The server rebinds backup versions of files and logical volume images in the following cases
When Management Class Rebinding effects backup copies
- The user changes the management class specified in the include-exclude list and does a backup.
- An administrator activates a policy set in the same policy domain as the client node, and the policy set does not contain a management class with the same name as the management class to which a file is currently bound.
- An administrator assigns a client node to a different policy domain, and the active policy set in that policy domain does not have a management class with the same name.
- Backup versions of a directory can be rebound when the user specifies a different management class using the DIRMC option in the client option file, and when the directory gets backed up.
- If a file is bound to a management class that no longer exists, the server uses the default management class to manage the backup versions. When the user does another backup, the server rebinds the file and any backup versions to the default management class. If the default management class does not have a backup copy group, the server uses the backup retention grace period specified for the policy domain.
When Management Class Rebinding effects Archive Copies
Archive copies are never rebound because each archive operation creates a different archive copy. Archive copies remain bound to the management class name specified when the user archived them.
Also Read: TSM Storage Pool Concepts (V7 Revised)
Also Read: TSM Storage Pool Concepts (V7 Revised)
If the management class to which an archive copy is bound no longer exists or no longer contains an archive copy group, the server uses the default management class. If you later change or replace the default management class, the server uses the updated default management class to manage the archive copy.
If the default management class does not contain an archive copy group, the server uses the archive retention grace period specified for the policy domain.
0 Comment to "What is TSM Management class Binding and Rebinding ?"
Post a Comment