![]() |
![]() |
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 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
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:
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
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):
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 |
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 |
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:
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.
Attention:
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.
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
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:
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:
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.
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.
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. 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. |
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.
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 correct the problems.
activate policyset engpoldom standard