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:
|
Policy Set | A new policy set in the same policy domain with:
|
Management Class | A new management class in the same policy set and a copy of each copy group in the management class |
Figure 45 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 45. 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:
When you update or define a policy domain, you specify:
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:
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.
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:
copy domain standard engpoldom
ENGPOLDOM now contains the standard policy set, management class, backup copy group, and archive copy group.
update domain engpoldom description='Engineering Policy Domain' backretention=90 archretention=730
When you define or update a policy set, specify:
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.
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:
copy policyset engpoldom standard test
Note: | When you copy an existing policy set, you also copy any associated management classes and copy groups. |
update policyset engpoldom test description='Policy set for testing'
When you define or update a management class, specify:
The following four parameters apply only to Tivoli Space Manager clients (HSM clients):
Note: | You cannot specify a copy storage pool as a destination. |
Create a new management class by following these steps:
define mgmtclass engpoldom standard mceng
update mgmtclass engpoldom standard mceng description='Engineering Management Class for Backup and Archive'
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" |
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. |
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:
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. |
You can specify how frequently files can be backed up with two parameters:
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.
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:
You specify the number of backup versions with two parameters:
You specify the number of days to keep backup versions with two parameters:
Use a combination of the four parameters: Versions Data Exists, Versions Data Deleted, Retain Extra Versions, and Retain Only Versions.
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 14 and Figure 46. 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 46. Active and Inactive Versions of REPORT.TXT
Table 15. 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 for details about the parameters. The following list gives some tips on using the NOLIMIT value:
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.
If NOLIMIT is specified, the last version is retained forever unless a user or administrator deletes the file from server storage.
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
To define or update an archive copy group on the Web interface or command line, specify:
Note: | You cannot specify a copy storage pool as a destination. |
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. |
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.
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
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.
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.
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.
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:
A backup, archive, or migration operation will fail when the operation involves storing a file in a storage pool that does not exist.
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.
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.
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 it contains a backup copy group. 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.
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.
Validating and activating the STANDARD policy set in the ENGPOLDOM policy domain is a two-step process:
validate policyset engpoldom standard
Examine any messages that result and rectify them.
activate policyset engpoldom standard
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.
Note: | A base file is not eligible for expiration until all its dependent subfiles have been expired. For details, see Expiration Processing of Base Files and Subfiles. |
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 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.
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.
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 Backup Volumes Onsite for more information.