Administrator's Guide


Creating Your Own Policies


Task Required Privilege Class
Define or copy a policy domain System
Update a policy domain over which you have authority Restricted policy
Define, update, or copy policy sets and management classes in any policy domain System or unrestricted policy
Define, update, or copy policy sets and management classes in policy domains over which you have authority Restricted policy
Define or update copy groups in any policy domain System or unrestricted policy
Define or update copy groups that belong to policy domains over which you have authority Restricted policy
Assign a default management class to a nonactive policy set in any policy domain System or unrestricted policy
Assign a default management class to a nonactive policy set in policy domains over which you have authority Restricted policy
Validate and activate policy sets in any policy domain System or unrestricted policy
Validate and activate policy sets in policy domains over which you have authority Restricted policy
Start inventory expiration processing System

You may need more flexibility in your policies than the standard policy provides. For example, you may want clients to be able to keep three instead of two backup versions of a file. You may want to change the backup copy group parameters, to enable clients to restore backed-up files to a specific point in time (see Setting Policy to Enable Point-in-Time Restore for Clients for more information).

You can create your own policies in one of two ways:

The following table shows that an advantage of copying existing policy parts is that some associated parts are copied in a single operation.

If you copy: You create:
Policy Domain A new policy domain with:

  • A copy of each policy set from the original domain

  • A copy of each management class in each original policy set

  • A copy of each copy group in each original management class
Policy Set A new policy set in the same policy domain with:

  • A copy of each management class in the original policy set

  • A copy of each copy group in the original management class
Management Class A new management class in the same policy set and a copy of each copy group in the management class

The sections that follow describe the tasks involved in creating new policies for your installation. Do the tasks in the following order:

  1. Define policy domains to manage groups of client nodes. See page "Defining and Updating a Policy Domain".

  2. Define policy sets for different policies. See "Defining and Updating a Policy Set".

  3. Define management classes to match users' requirements. See "Defining and Updating a Management Class".

  4. Define backup copy groups to specify which files can be backed up and how to manage backup versions. See "Defining and Updating a Backup Copy Group".

  5. Define archive copy groups to specify whether a file can be archived if it is in use and to manage archive copies. See "Defining and Updating an Archive Copy Group".

  6. Assign a default management class to each policy set to match the most common requirements of client nodes in the policy domain. See "Assigning a Default Management Class".

  7. Validate all policy sets, and activate one policy set for each policy domain. See "Activating a Policy Set".

  8. Set the frequency of expiration processing to delete files according to policies. See "Running Expiration Processing to Delete Expired Files".

Example: Sample Policy Objects

Figure 43 shows the policies for an engineering department. This example is used throughout the rest of this chapter.

The domain contains two policy sets that are named STANDARD and TEST. The administrator activated the policy set that is named STANDARD. When you activate a policy set, the server makes a copy of the policy set and names it ACTIVE. Only one policy set can be active at a time.

The ACTIVE policy set contains three management classes: ENGINEERING, MCENG, and MCENGBK3. The default management class is MCENG.

Figure 43. An Example of Policy Objects Defined for an Engineering Department

An Example of Policy Objects Defined for an Engineering Department


Defining and Updating a Policy Domain

When you update or define a policy domain, you specify:

Backup Retention Grace Period
Specifies the number of days to retain an inactive backup version when the server cannot rebind the file to an appropriate management class. The backup retention grace period protects backup versions from being immediately expired when the management class to which a file is bound no longer exists or no longer contains a backup copy group, and the default management class does not contain a backup copy group.

Backup versions of the file managed by the grace period are retained in server storage only for the backup retention grace period. This period starts from the day of the backup. For example, if the backup retention grace period for the STANDARD policy domain is used and set to 30 days, backup versions using the grace period expire in 30 days from the day of the backup.

Backup versions of the file continue to be managed by the grace period unless one of the following occurs:

Archive Retention Grace Period
Specifies the number of days to retain an archive copy when the management class for the file no longer contains an archive copy group and the default management class does not contain an archive copy group. The retention grace period protects archive copies from being immediately expired.

The archive copy of the file managed by the grace period is retained in server storage for the number of days specified by the archive retention grace period. This period starts from the day on which the file is first archived. For example, if the archive retention grace period for the policy domain STANDARD is used, an archive copy expires 365 days from the day the file is first archived.

The archive copy of the file continues to be managed by the grace period unless an archive copy group is added to the file's management class or to the default management class.

Example: Defining a Policy Domain

To create a new policy domain you can do one of the following:

Note:When you copy an existing domain, you also copy any associated policy sets, management classes, and copy groups.

For example, to copy and update, follow this procedure:

  1. Copy the STANDARD policy domain to the ENGPOLDOM policy domain by entering:
    copy domain standard engpoldom
    

    ENGPOLDOM now contains the standard policy set, management class, backup copy group, and archive copy group.

  2. Update the policy domain ENGPOLDOM so that the backup retention grace period is extended to 90 days and the archive retention grace period is extended to 2 years by entering:
    update domain engpoldom description='Engineering Policy Domain'
    backretention=90 archretention=730
    

Defining and Updating a Policy Set

When you define or update a policy set, specify:

Policy domain name
Names the policy domain to which the policy set belongs

The policies in the new policy set do not take effect unless you make the new set the ACTIVE policy set. See Activating a Policy Set.

Example: Defining a Policy Set

An administrator needs to develop new policies based on the existing STANDARD policy set. To create the TEST policy set in the STANDARD policy domain, the administrator performs the following steps:

  1. Copy the STANDARD policy set and name the new policy set TEST:
    copy policyset standard standard test
    
    Note:When you copy an existing policy set, you also copy any associated management classes and copy groups.

  2. Update the description of the policy set named TEST:
    update policyset standard test
    description='Policy set for testing'
    

Defining and Updating a Management Class

When you define or update a management class, specify:

Policy domain name
Names the policy domain to which the management class belongs.

Policy set name
Names the policy set to which the management class is assigned.

Description
Describes the management class. A clear description can help users to choose an appropriate management class for their use.

The following four parameters apply only to Tivoli Space Manager clients (HSM clients):

Whether space management is allowed
Specifies that the files are eligible for both automatic and selective migration, only selective migration, or no migration.

How frequently files can be migrated
Specifies the minimum number of days that must elapse since a file was last accessed before it is eligible for automatic migration.

Whether backup is required
Specifies whether a backup version of a file must exist before the file can be migrated.

Where migrated files are to be stored
Specifies the name of the storage pool in which migrated files are stored. Your choice could depend on factors such as:
Note:You cannot specify a copy storage pool as a destination.

Example: Define a New Management Class

Create a new management class containing a backup copy group and an archive copy group by doing the following steps:

  1. Copy the STANDARD management class from the STANDARD policy set to the new management class (named MCENG) by entering:
    copy mgmtclass engpoldom standard standard mceng
    

    The server copies the management class description, standard backup copy group, and standard archive copy group to MCENG.

  2. Update the description of the MCENG management class by entering:

    update mgmtclass engpoldom standard mceng
    description='Engineering Management Class with Backup and Archive Copy Groups'
    

Defining and Updating a Backup Copy Group

You can specify the following policies in a backup copy group:

Where to Store Backed-Up Files

Specify a storage pool where the server initially stores the files associated with this backup copy group. Your choice can depend on factors such as:

Note:You cannot specify a copy storage pool.

Whether Files Can Be Modified During Backup

You can specify how files are handled if they are modified while being backed up and what happens if modification occurs. The attribute, called serialization, can be one of four values: static, shared static, dynamic, and shared dynamic. The value you choose depends on whether you want to allow modification during backup:

Prevent modification during backup
For most files, you will want to prevent the server from backing up a file while it is being modified. Use one of the following values:

Static
Specifies that if the file or directory is modified during a backup, TSM does not back it up. TSM does not retry the backup.

Shared Static
Specifies that if the file or directory is modified during a backup, TSM does not back it up. However, TSM retries the backup as many times as specified by the CHANGINGRETRIES option in the client options file.

Allow modification during backup
You may want to define a copy group that allows modification during backup for files where log records are continuously added, such as an error log. If you only have copy groups that prevent modification (static or shared static), these files may never be backed up because they are constantly in use. To allow modification during backup, use one of the following values:

Dynamic
Specifies that a file or directory is backed up on the first attempt, even if the file or directory is being modified during the backup.

Shared Dynamic
Specifies that if a file or directory is modified during a backup attempt, TSM backs it up on its last try even if the file or directory is being modified. TSM retries the backup as many times as specified by the CHANGINGRETRIES option in the client options file.

Attention: If a file is backed up while it is in use (shared dynamic or dynamic serialization), the copy may not contain all the changes and may not be usable. For example, the backup version may contain a truncated record.

Note:When certain users or processes open files, they deny read access to the files for any other user or process. When this happens, even with serialization set to dynamic or shared dynamic, TSM does not back up the file.

How Frequently Files Can Be Backed Up

You can specify how frequently files can be backed up with two parameters:

Frequency
The frequency is the minimum number of days that must elapse between full incremental backups.

Mode
The mode parameter specifies whether a file or directory must have been modified to be considered for full incremental backup. TSM does not check this attribute when a user requests a partial incremental backup, a selective backup for a file, or a backup of a logical volume. You can select from two modes:

Modified
A file is considered for full incremental backup only if it has changed since the last backup. A file is considered changed if any of the following items is different:
  • Date on which the file was last modified
  • File size
  • File owner
  • File permissions

Absolute
A file is considered for full incremental backup regardless of whether it has changed since the last backup.

The server considers both parameters to determine how frequently files can be backed up. For example, if frequency is 3 and mode is modified, a file or directory is backed up only if it has been changed and if three days have passed since the last backup. If frequency is 3 and mode is absolute, a file or directory is backed up after three days have passed whether or not the file has changed.

Use the modified mode when you want to ensure that the server retains multiple, different backup versions. If you set the mode to absolute, users may find that they have three identical backup versions, rather than three different backup versions.

Absolute mode can be useful for forcing a full backup. It can also be useful for ensuring that OS/2 files with extended attributes are backed up, because TSM does not detect changes to the extended attributes.

When you set the mode to absolute, set frequency to 0 if you want to ensure that a file is backed up each time full incremental backups are scheduled for or initiated by a client.

How Many Backup Versions to Retain and For How Long

Multiple versions of files are useful when users continually update files and sometimes need to restore the original file from which they started. The most current backup version of a file is called the active version. All other versions are called inactive versions. You can specify the number of versions to keep by:

These parameters interact to determine the backup versions that the server retains. When the number of inactive backup versions exceeds the number of versions allowed (Versions Data Exists and Versions Data Deleted), the oldest version expires and the server deletes the file from the database the next time expiration processing runs. How many inactive versions the server keeps is also related to the parameter for how long inactive versions are kept (Retain Extra Versions). Inactive versions expire when the number of days that they have been inactive exceeds the value specified for retaining extra versions, even when the number of versions is not exceeded.

For example, see Table 14 and Figure 44. A client node has backed up the file REPORT.TXT four times in one month, from March 23 to April 23. The settings in the backup copy group of the management class to which REPORT.TXT is bound determine how the server treats these backup versions. Table 15 shows some examples of how different copy group settings would affect the versions. The examples show the effects as of April 24 (one day after the file was last backed up).

Table 14. Status of REPORT.TXT as of April 24

Version Date Created Days the Version Has Been Inactive
Active April 23 (not applicable)
Inactive 1 April 13 1 (since April 23)
Inactive 2 March 31 11 (since April 13)
Inactive 3 March 23 24 (since March 31)

Figure 44. Active and Inactive Versions of REPORT.TXT

Example of Active and Inactive Versions of Backed Up Files



Table 15. Effects of Backup Copy Group Policy on Backup Versions for REPORT.TXT as of April 24

Effects as of April 24 (one day after the file was last backed up)
Versions Data Exists Versions Data Deleted Retain Extra Versions Retain Only Version Results
3 versions 2 versions 60 days 180 days Versions Data Exists and Retain Extra Versions control the expiration of the versions. The version created on March 23 is retained until the client node backs up the file again (creating a fourth inactive version), or until that version has been inactive for 60 days.

If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted and Retain Only Version parameters also have an effect. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire). The April 13 version expires when it has been inactive for 60 days (on June 23). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive.

3 versions 2 versions 21 days 180 days Retain Extra Versions makes the version created on March 23 eligible for expiration, because that version has been inactive for more than 21 days. The version created on March 23 is marked as expired the next time that the server runs expiration processing.

If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted and Retain Only Version parameters also have an effect. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire) because only two versions are allowed. The April 13 version expires when it has been inactive for 21 days (on May 14). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive.

NOLIMIT 2 versions 60 days 180 days Retain Extra Versions controls expiration of the versions. The inactive versions (other than the last remaining version) are expired when they have been inactive for 60 days.

If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted and Retain Only Version parameters also have an effect. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire) because only two versions are allowed. The April 13 version expires when it has been inactive for 60 days (on June 23). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive.

3 versions 2 versions NOLIMIT NOLIMIT Versions Data Exists controls the expiration of the versions until a user deletes the file from the client node. The server does not expire inactive versions based on age.

If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. From that point, the Versions Data Deleted parameter controls expiration. All versions are now inactive. Two of the four versions expire immediately (the March 23 and March 31 versions expire) because only two versions are allowed. The server keeps the two remaining inactive versions indefinitely.

The following list gives more details for the four parameters, and some tips on using the NOLIMIT value:

Versions Data Exists
The maximum number of backup versions that the server retains for files and directories that still exist on the client node.

Setting the value to NOLIMIT may require increased storage, but that value may be needed for some situations. For example, to enable client nodes to restore files to a specific point in time, set the value for Versions Data Exists to NOLIMIT. Setting the value this high ensures that the server retains versions according to the Retain Extra Versions parameter for the copy group. See Setting Policy to Enable Point-in-Time Restore for Clients and Policy for Logical Volume Backups for more information.

Versions Data Deleted
The maximum number of backup versions that the server retains for files and directories that have been erased from a client node. The server ignores this parameter while the file or directory remains on the node.

If users erase a file or directory from their client nodes, then the next time a full incremental backup is run, the server changes the active backup version to inactive. The oldest versions that are more than the number specified by this parameter then expire, and the server deletes them the next time expiration processing runs.

The expiration date for the remaining versions is based on the Retain Extra Versions and Retain Only Version parameters.

Setting the value to NOLIMIT may require increased storage, but that value may be needed for some situations. For example, set the value for Versions Data Deleted to NOLIMIT to enable client nodes to restore files to a specific point in time. Setting the value this high ensures that the server retains versions according to the Retain Extra Versions parameter for the copy group. See Setting Policy to Enable Point-in-Time Restore for Clients and Policy for Logical Volume Backups for more information.

Retain Extra Versions
Specifies how many days the server retains a backup version after that version becomes inactive. A version of a file becomes inactive when the client stores a more recent backup version, or when the client deletes the file from the workstation and then runs a full incremental backup. The value of this parameter determines which versions are deleted during inventory expiration processing.

If NOLIMIT is specified, inactive backup versions are deleted based on the Versions Data Exists or Versions Data Deleted parameters.

To enable client nodes to restore files to a specific point in time, set the parameters Versions Data Exists or Versions Data Deleted to NOLIMIT. Set the value for Retain Extra Versions to the number of days that you expect clients may need versions of files available for possible point-in-time restoration. For example, to enable clients to restore files from a point in time 60 days in the past, set Retain Extra Versions to 60. See Setting Policy to Enable Point-in-Time Restore for Clients for more information.

Retain Only Version
Specifies how many days the server retains the only backup version it has of a file when the original file has been deleted from the workstation.

If NOLIMIT is specified, the last version is retained forever unless a user or administrator deletes the file from server storage.

Example: Define a Backup Copy Group

Define a backup copy group belonging to the MCENG management class in the STANDARD policy set belonging to the ENGPOLDOM policy domain. This new copy group must do the following:

To define the backup copy group, enter:

define copygroup engpoldom standard mceng standard
destination=engback1 serialization=static
verexists=5 verdeleted=4 retextra=90 retonly=600

Defining and Updating an Archive Copy Group

To define or update an archive copy group on the graphical user interface or command line, specify:

Where archived files are to be stored
Specifies a defined storage pool. Your choice can depend on factors such as:
Note:You cannot specify a copy storage pool as a destination.

If files can be modified during archive
Specifies how files are handled if they are modified while being archived and what happens if modification occurs. This attribute, called serialization, can be one of four values:

Static
Specifies that if the file is modified during an archiving process, TSM does not archive it. TSM does not retry the archive.

Shared Static
Specifies that if the file is modified during an archive process, TSM does not archive it. However, TSM retries the archive process as many times as specified by the CHANGINGRETRIES option in the client options file.

Dynamic
Specifies that a file is archived on the first attempt, even if the file is being modified during the archive process.

Shared Dynamic
Specifies that if the file is modified during the archive attempt, TSM archives it on its last try even if the file is being modified. TSM retries the archive process as many times as specified by the CHANGINGRETRIES option in the client options file.

For most files, set serialization to either static or shared static to prevent the server from archiving a file while it is being modified.

However, you may want to define a copy group with a serialization of shared dynamic or dynamic for files where log records are continuously added, such as an error log. If you only have copy groups that use static or shared static, these files may never be archived because they are constantly in use. With shared dynamic or dynamic, the log files are archived. However, the archive copy may contain a truncated message.

Attention: If a file is archived while it is in use (shared dynamic or dynamic serialization), the copy may not contain all the changes and may not be usable.

Note:When certain users or processes open files, they deny read access to the files for any other user or process. When this happens, even with serialization set to dynamic or shared dynamic, TSM does not back up the file.

How long to retain an archived copy
Specifies the number of days to retain an archived copy in storage. When the time elapses, the archived copy expires and the server deletes the file the next time expiration processing runs.

When a user archives directories without using the ARCHMC option, the server uses the default management class. If the default management class does not have an archive copy group, the server binds the directory to the management class that currently has the shortest retention time for archive. When you change the retention time for an archive copy group, you may also be changing the retention time for any directories that were archived using that copy group.

Example: Define an Archive Copy Group

Define an archive copy group belonging to the MCENG class that:

To define a STANDARD archive copy group to the MCENG management class in the STANDARD policy set belonging to the ENGPOLDOM policy domain, enter:

define copygroup engpoldom standard mceng standard
type=archive destination=engarch1 serialization=static
retver=730

Assigning a Default Management Class

After you have defined a policy set and the management classes that it contains, you must assign a default management class for the policy set. See Default Management Classes for suggestions about the content of default management classes.

Example: Assign a Default Management Class

To assign the STANDARD management class as the default management class for the TEST policy set in the STANDARD policy domain, enter:

assign defmgmtclass standard test standard

The STANDARD management class was copied from the STANDARD policy set to the TEST policy set (see Example: Defining a Policy Set). Before the new default management class takes effect, you must activate the policy set.

Validating and Activating a Policy Set

After you have defined a policy set and defined management classes to it, you can validate the policy set and activate the policy set for the policy domain. Only one policy set is active in a policy domain.

Validating a Policy Set

When you validate a policy set, the server examines the management class and copy group definitions in the policy set and reports on conditions that need to be considered if the policy set is activated.

Validation fails if the policy set does not contain a default management class. The following conditions result in warning messages during validation:

Activating a Policy Set

To activate a policy set, specify a policy domain and policy set name. When you activate a policy set, the server:

After a policy set has been activated, the original and the ACTIVE policy sets are two separate objects. For example, updating the original policy set has no effect on the ACTIVE policy set. You cannot update the ACTIVE policy set. To change its contents, you must create or change another policy set and then activate that policy set. See Changing Policy with the Active Policy Set for details.

Example: Validating and Activating a Policy Set

Validating and activating the TEST policy set in the STANDARD policy domain is a two-step process:

  1. To validate the TEST policy set, enter:
    validate policyset standard test
    

    Examine any messages that result.

  2. To activate the TEST policy set, enter:
    activate policyset standard test
    

Running Expiration Processing to Delete Expired Files

Files expire under the following conditions:

File expiration that is triggered by an event such as a file being deleted or a version becoming an extra inactive version occurs when the client backup process runs successfully. File expiration that is based on time criteria (such as how many days a file is inactive or how long to keep a backup set) occurs when the expiration process runs on the server.

The server does not delete information about the expired files from the server database until expiration processing runs. You can run expiration processing either automatically or by command. You control automatic expiration processing by using the expiration interval option (EXPINTERVAL) in the server options file (dsmserv.opt). You can set the option by editing the dsmserv.opt file (see Administrator's Reference).

If you use the server option to control when expiration processing occurs, the server runs expiration processing each time you start the server. After that, the server runs expiration processing at the interval you specified with the option, measured from the start time of the server.

You can manually start expiration processing by issuing the following command:

expire inventory

Expiration processing then deletes information about expired files from the database. You can schedule this command by using the DEFINE SCHEDULE command. If you schedule the EXPIRE INVENTORY command, set the expiration interval to 0 in the server options so that the server does not run expiration processing when you start the server.

You can control how long the expiration process runs by using the DURATION parameter with the EXPIRE INVENTORY command.

When expiration processing runs, the server normally sends detailed messages about policy changes made since the last time expiration processing ran. The messages are about changes you made that affect client files, such as deleting a management class or a copy group. You can reduce the number of messages about policy changes that are generated during expiration processing by using the EXPQUIET option in the server options, or the QUIET=YES parameter with the EXPIRE INVENTORY command. When you use the quiet option or parameter, the server issues messages about policy changes during expiration processing only when files are deleted, and either the default management class or retention grace period for the domain has been used to expire the files.

Additional Expiration Processing with Tivoli Disaster Recovery Manager: If you have Tivoli Disaster Recovery Manager (DRM), one or more database backup volumes may also be deleted during expiration processing if the following conditions are true:

See Moving Reclaimed or Expired Volumes Back Onsite for more information.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]