Management classes are the key connection between client files and policy.
Each client node is assigned to a single policy domain, and the client node has access only to the management classes contained in the active policy set. The management classes specify whether client files are migrated to storage pools (hierarchical storage management). The copy groups in these management classes specify the number of backup versions retained in server storage and the length of time to retain backup versions and archive copies.
For example, if a group of users needs only one backup version of their files, you can create a policy domain that contains only one management class whose backup copy group allows only one backup version. Then you can assign the client nodes for these users to the policy domain. See Registering Nodes with the Server for information on registering client nodes and assigning them to policy domains.
The following sections give you more information about management classes and how they work with other parts of Tivoli Storage Manager:
A management class contains policy for backup, archive, and space management operations by clients. You can specify if and how a Tivoli Space Manager client can migrate files to server storage with parameters in the management class. For clients using the server for backup and archive, you can choose what a management class contains from the following options:
Attention: A management class that contains neither a backup nor an archive copy group prevents a file from ever being backed up or archived. This type of management class is not recommended for most users. Use such a management class carefully to prevent users from mistakenly selecting it. If users bind their files to a management class without copy groups, TSM issues warning messages.
Each policy set must include a default management class, which is used for the following purposes:
A typical default management class should do the following:
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.
A user can define an include-exclude list to specify which files are eligible for backup services, which files can be migrated from the client (space-managed), and how the server manages backed-up, archived, and space-managed files.
If a user does not create an include-exclude list, the following default conditions apply:
With an include-exclude list, users can:
For example, Figure 46 shows that the SSTEINER node ID excludes all core files from being eligible for backup and client migration.
For example, Figure 46 shows that the files in the /home/ssteiner directory are excluded. The include statement that follows, however, means that the /home/ssteiner/options.scr file is eligible for backup and client migration.
For example, Figure 46 shows that all files and subdirectories belonging to the /home/ssteiner/driver5 directory are managed by the criteria defined in the MCENGBK2 management class.
Figure 46. Example of an Include-Exclude List
+--------------------------------------------------------------------------------+ |exclude /.../core | |exclude /home/ssteiner/* | |include /home/ssteiner/options.scr | |include /home/ssteiner/driver5/.../* mcengbk2 | +--------------------------------------------------------------------------------+
TSM processes the include-exclude list from the bottom up, and stops when it finds an include or exclude statement that matches the file it is processing. Therefore, the order in which the include and exclude options are listed affects which files are included and excluded. For example, suppose you switch the order of two lines in the example, as follows:
include /home/ssteiner/options.scr exclude /home/ssteiner/*
The exclude statement comes last, and excludes all files in the /home/ssteiner directory. When TSM is processing the include-exclude list for the options.scr file, it finds the exclude statement first. This time, the options.scr file is excluded.
You can create include-exclude lists as part of a client options set that you define for clients. For information on defining client option sets and assigning a client option set to a client, see Modifying Client Option Files. For information on how to create an include-exclude list, see the user's publication for the appropriate client.
Binding is the process of associating a file with a management class. The policies defined in the management class then apply to the bound files. The server binds a file to a management class when a client backs up, archives, or migrates the file. A client chooses a management class as follows:
For directories, the client can specify a management class by using the DIRMC option in the client options file. 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).
For directories, the client can specify a management class with the ARCHMC option. If the client does not specify the ARCHMC option, 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.
The default management class is the management class identified as the default in the active policy set.
If a client backs up, archives, and migrates a file to the same server, the management class specified for a file using an include-exclude option 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. See the user's publication for the appropriate client for details.
A file remains bound to a management class even if the attributes of the management class change. The following scenario illustrates this process:
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:
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.
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.
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.