Administrator's Guide

More on Management Classes

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 domain. 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 ADSM 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 "Administrator Registration of Client Nodes" for information on registering client nodes and assigning policy domains to them.

The following sections give you more information about management classes and how they work with other parts of ADSM:

• "Contents of a Management Class"

• "Default Management Classes"

• "The Include-Exclude List"

• "How Files Are Associated with a Management Class"

• "How Files Are Deleted"

Contents of a Management Class

You can choose what a management class contains. You have the following options:

A backup copy group and an archive copy group

For example, most users need to back up and archive documents, spread sheets, and graphics.

A backup copy group only

For example, some users only want to back up application files (such as database, log, or history files that change daily).

An archive copy group only

A management class that contains only an archive copy group is useful for users who create:

• Point-in-time files. For example, an engineer can archive the design of an electronic component and the software that created the design. Later, the engineer can use the design as a base for a new electronic component.

• Files that are rarely used but need to be retained for a long time. A client can erase the original file without affecting how long the archive copy is retained in ADSM storage. Examples include legal records, patient records, and tax forms.

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, ADSM issues warning messages.

Default Management Classes

Each policy set must include a default management class, which 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 a management class name is deleted from the server as described in "How Files Are Associated with a Management Class".

• To manage existing archive copies when a management class is deleted from the server. ADSM does not rebind archive copies but does use the archive copy group (if one exists) in the default management class.

A typical default management class should do the following:

• 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.

The Include-Exclude List

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 ADSM manages backed-up, archived, and space-managed files.

If a user does not create an include-exclude list, the following default conditions apply:

• All files belonging to the user are eligible for backup services.

• The default management class governs backup, archive, and space-management policies.

With an include-exclude list, users can:

• Exclude files or directories from backup and client migration operations

  For example, Figure 38 shows that the SSTEINER node ID excludes all core files from being eligible for backup and client migration.

• Include any previously excluded files

  For example, Figure 38 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.

• Bind a file to a specific management class

  For example, Figure 38 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 38. Example of an Include-Exclude List

+--------------------------------------------------------------------------------+
|exclude /.../core                                                               |
|exclude /home/ssteiner/*                                                        |
|include /home/ssteiner/options.scr                                              |
|include /home/ssteiner/driver5/.../* mcengbk2                                   |
+--------------------------------------------------------------------------------+

ADSM 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. The order in which the include and exclude options are listed therefore affect 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/steiner directory. When ADSM 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 "Defining Client Options from the Server". For information on how to create an include-exclude list, see the user's publication for the appropriate client.

How Files Are Associated with a Management Class

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. ADSM 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 backing up a file, a client can specify a management class in the client's include-exclude list (include-exclude options file for UNIX clients), or can accept the default management class.

  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, ADSM chooses the management class with the longest retention period in the backup copy group (retention period for the only backup version).

• For archiving a file, the client can specify a management class in the client's include-exclude list, can specify a management class with the ARCHMC option on the archive command, or can accept the default management class.

• 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. 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:

1. 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.

2. During the next week, three backup versions of REPORT.TXT are stored in ADSM storage. The active and two inactive backup versions are bound to the default management class.

3. The administrator assigns a new default management class that contains a backup copy group specifying only up to two backup versions.

4. The administrator then activates the policy set, and the new default management class takes effect.

5. REPORT.TXT is backed up again, bringing the number of versions to four. ADSM determines that according to the new backup copy group only two versions are to be retained. Therefore, ADSM marks the two oldest versions for deletion.

6. Expiration processing occurs (see "How Files Are Deleted" for details). 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.

Rebinding Files to Management Classes

Rebinding is the process of associating a file with a new management class. ADSM rebinds backup versions of files in the following cases:

• 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, ADSM uses the default management class to manage the backup versions. When the user does another backup, ADSM rebinds the file and any backup versions to the default management class. If the default management class does not have a backup copy group, ADSM uses the backup retention grace period specified for the policy domain.

Note:

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 no longer exists or no longer contains an archive copy group, ADSM uses the default management class. If the default management class does not contain an archive copy group, ADSM uses the archive retention grace period specified for the policy domain.

How Files Are Deleted

Management classes contain the backup and archive copy groups that specify the criteria that make copies of files eligible for deletion from server storage. However, even when a file becomes eligible for deletion, information about the file is not deleted from the database until expiration processing occurs. If expiration processing does not occur periodically, the ADSM server cannot reuse storage pool space occupied by expired client files, and requires increased storage space.

See "Running Expiration Processing to Delete Expired Files" for details about how to invoke expiration processing.