Tivoli Storage Manager for Windows 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 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 two management classes: MCENG and STANDARD. The default management class is STANDARD.

Figure 43. 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 with Backup and Archive Copy Groups'
    

Defining and Updating a Backup Copy Group


Tasks:
"Where to Store Backed-Up Files"
"Whether Files Can Be 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. 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 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.

For example, see Table 21 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 22 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 21. 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 22. 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.

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

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 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 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 rectify them.

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

Running Expiration Processing to Delete Expired Files

Expiration processing deletes expired client files from the server storage. You can run expiration processing either automatically or by command. You should ensure that expiration processing runs periodically to allow the server to reuse storage pool space that is occupied by expired client files.

Running Expiration Processing Automatically

You control automatic expiration processing by using the expiration interval option (EXPINTERVAL) in the server options file (dsmserv.opt). You can set the option through the TSM Server Utilities or by editing the dsmserv.opt file (see Administrator's Reference).

You may follow these steps to set the expiration interval option through the TSM Server Utilities:

  1. Click the Server Options in the TSM Server Utilities tree. The Options Files appear in the right panel.
  2. Select a TSM Server in the Installed TSM Servers list.
  3. Click Edit.
  4. Click Server Processing.
  5. Set the value for expiration interval and whether to use quiet expiration, as desired.
  6. Click Save on the File menu of the TSM Server Utilities.

If you use the server options file to control automatic expiration, 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.

Using Commands and Scheduling to Control Expiration Processing

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

expire inventory

Expiration processing then deletes 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. You can reduce those messages by checking the Use Quiet Expiration option in the server options, or using 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 ]