Tivoli Header

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 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 this... Then you create this...
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

Example: Sample Policy Objects

Figure 39 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 two management classes: MCENG and STANDARD. The default management class is STANDARD.

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

An Example of Policy Objects Defined for an Engineering Department

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

Tasks:
Defining and Updating a Policy Domain
Defining and Updating a Policy Set
Defining and Updating a Management Class
Defining and Updating a Backup Copy Group
Defining and Updating an Archive Copy Group
Assigning a Default Management Class
Activating a Policy Set
Running Expiration Processing to Delete Expired Files.

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 ENGPOLDOM policy domain, the administrator performs the following steps:

  1. Copy the STANDARD policy set and name the new policy set TEST:
    copy policyset engpoldom 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 engpoldom 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 by following these steps:

  1. Define a new management class MCENG by entering:
    define mgmtclass engpoldom standard mceng
    
  2. Update the description of the MCENG management class by entering:

    update mgmtclass engpoldom standard mceng
    description='Engineering Management Class for Backup and Archive'
    

Defining and Updating a Backup Copy Group


Tasks:
Where to Store Backed-Up Files
How to Handle Files That Are Modified During Backup
How Frequently Files Can Be Backed Up
How Many Backup Versions to Retain and For How Long

Where to Store Backed-Up Files

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

Note:
You cannot specify a copy storage pool.

How to Handle Files That Are Modified During Backup

You can use the SERIALIZATION attribute on the DEFINE COPYGROUP command to specify how files are handled if they are modified during a backup. This attribute can be one of four values: STATIC, SHRSTATIC (shared static), DYNAMIC, or SHRDYNAMIC (shared dynamic). The value you choose depends on how you want Tivoli Storage Manager to handle files that are modified while they are being backed up.

Do not back up files that are modified during the backup
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 Tivoli Storage Manager will attempt to back up the file only once. If the file or directory is modified during a backup, the server does not back it up.

SHRSTATIC (Shared static)
Specifies that if the file or directory is modified during a backup, the server retries the backup as many times as specified by the CHANGINGRETRIES option in the client options file. If the file is modified during the last attempt, the file or directory is not backed up.

Back Up Files That Are Modified During the Backup
Some files are in constant use, such as an error log. Consequently, these files may never be backed up when serialization is set to STATIC or SHRSTATIC. To back up files that are modified during the 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 modified during the backup.

SHRDYNAMIC (Shared dynamic)
Specifies that if a file or directory is modified during a backup, the server retries the backup as many times as specified by the CHANGINGRETRIES option in the client options file. The server backs up the file on the last attempt, even if the file or directory is being modified.

Attention:

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.
Note:
For Windows NT and Windows 2000 this attribute is ignored during a journal-based backup.

Mode
The mode parameter specifies whether a file or directory must have been modified to be considered for backup during a full incremental backup process. Tivoli Storage Manager 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 extended attribute files are backed up, because TSM does not detect changes if the size of the extended attribute file remains the same.

When you set the mode to Absolute, set the 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.

Note:
A base file is not eligible for expiration until all its dependent subfiles have been expired. For details, see Enabling Clients to Use Subfile Backup.

For example, see Table 19 and Figure 40. 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 20 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 19. 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 40. Active and Inactive Versions of REPORT.TXT

Example of Active and Inactive Versions of Backed Up Files


Table 20. Effects of Backup Copy Group Policy on Backup Versions for REPORT.TXT 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.

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 22). The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive.

NOLIMIT NOLIMIT 60 days 180 days Retain Extra Versions controls expiration of the versions. The server does not expire inactive versions based on the maximum number of backup copies. 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 Retain Only Version parameter also has an effect. All versions are now inactive. The three of four versions will expire after each of them has been inactive for 60 days. 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.

See Administrator's Reference for details about the parameters. The following list gives some tips on using the NOLIMIT value:

Versions Data Exists
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
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

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

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 Web interface or command line, specify:

Where archived files are to be stored
Specify a defined storage pool as the initial destination. 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
Specify how files are handled if they are modified while being archived. This attribute, called serialization, can be one of four values:

Static
Specifies that if the file is modified during an archiving process, the server does not archive it. Tivoli Storage Manager does not retry the archive.

Shared Static
Specifies that if the file is modified during an archive process, the server does not archive it. However, Tivoli Storage Manager 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, the server archives it on its last try even if the file is being modified. Tivoli Storage Manager 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, the server 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, the server uses the default management class unless the user specifies otherwise. 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.

The user can change the archive characteristics by using Archive Options in the interface or by using the ARCHMC option on the command.

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 ENGPOLDOM policy domain, enter:

assign defmgmtclass engpoldom standard 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. Validation results in result in warning messages if any of the following conditions exist.

Condition Reason for warning
The storage destinations specified for backup, archive, or migration do not refer to defined storage pools. A backup, archive, or migration operation will fail when the operation involves storing a file in a storage pool that does not exist.
A storage destination specified for backup, archive, or migration is a copy storage pool. The storage destination must be a primary storage pool.
The default management class does not contain a backup or archive copy group. When the default management class does not contain a backup or archive copy group, any user files bound to the default management class are not backed up or archived.
The current ACTIVE policy set names a management class that is not defined in the policy set being validated. When users back up files that were bound to a management class that no longer exists in the active policy set, backup versions are rebound to the default management class. See How Files and Directories Are Associated with a Management Class for details.

When the management class to which an archive copy is bound no longer exists and the default management class does not contain an archive copy group, the archive retention grace period is used to retain the archive copy. See Defining and Updating a Policy Domain for details.

The current ACTIVE policy set contains copy groups that are not defined in the policy set being validated. When users perform a backup and the backup copy group no longer exists in the management class to which a file is bound, backup versions are managed by the default management class. If the default management class does not contain a backup copy group, backup versions are managed by the backup retention grace period, and the workstation file is not backed up. See Defining and Updating a Policy Domain
A management class specifies that a backup version must exist before a file can be migrated from a client node, but the management class does not contain a backup copy group. The contradictions within the management classes can cause problems for HSM users.

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:

You cannot update the ACTIVE policy set; 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. To change the contents of the ACTIVE policy set, you must create or change another policy set and then activate that policy set. See Changing Policy for details.

Example: Validating and Activating a Policy Set

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

  1. To validate the STANDARD policy set, enter:
    validate policyset engpoldom standard
    

    Examine any messages that result and correct the problems.

  2. To activate the STANDARD policy set, enter:
    activate policyset engpoldom standard
    


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