![]() |
![]() |
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, Tivoli Storage Manager 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 the different processes that the client can run. Include and exclude options in the list determine which files are eligible for backup and archive 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:
Figure 46 shows an example of an include-exclude list. The statements in this example list do the following:
Line 1 in Figure 46 means that the SSTEINER node ID excludes all core files from being eligible for backup and client migration.
Line 2 in Figure 46 means that the files in the /home/ssteiner directory are excluded. The include statement that follows on line 3, however, means that the /home/ssteiner/options.scr file is eligible for backup and client migration.
Line 4 in Figure 46 means that all files and subdirectories belonging to the /home/ssteiner/driver5 directory are managed by the policy 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 | +--------------------------------------------------------------------------------+
Tivoli Storage Manager 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 Tivoli Storage Manager 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.
Some options are evaluated after the more basic include and exclude options. For example, options that exclude or include files for compression are evaluated after the program determines which files are eligible for the process being run.
You can create include-exclude lists as part of client options sets that you define for clients. For information on defining client option sets and assigning a client option set to a client, see Creating Client Option Sets from the Server.
For detailed information on the include and exclude options, see the user's guide 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:
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:
See the user's guide for the appropriate client for details.
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:
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.