![]() |
![]() |
[ | | | ]
Storage management policies are rules your administrator defines in order to manage your backups and archives on the server. You can associate (or bind) your data to these policies; then when the data is backed up or archived, it is managed according to policy criteria. Policy criteria include a policy domain, a policy set, a copy group, and a management class.
Policies determine:
This chapter explains:
A policy domain is a group of clients with similar requirements for backing up and archiving data. Policy domains contain one or more policy sets. An administrator uses policy domains to manage a group of client nodes in a logical way. For example, a policy domain might include:
Tivoli Storage Manager includes a default policy domain named Standard. At first, your client node might be associated with the default policy domain. However, your administrator can define additional policy domains if there are groups of users with unique backup and archive requirements.
A policy set is a group of one or more management classes. Each policy domain can hold many policy sets. The administrator uses a policy set to implement different management classes based on business and user needs. Only one of these policy sets can be active at a time. This is called the active policy set. Each policy set contains a default management class and any number of additional management classes.
A management class is a collection of backup and archive copy groups that establishes and contains specific storage management requirements for backing up and archiving data. An administrator can establish separate management classes to meet the backup and archive requirements for different kinds of data, such as:
Most of the work you do with storage management policies is with management classes. You must associate (or bind) each file and directory that you back up and each file that you archive with a management class:
You can use include statements in your include-exclude list to associate files with management classes. See Selecting a management class for files for more information. In your client system options file (dsm.sys), you can associate directories with a management class, using the dirmc option. See Selecting a management class for directories for more information.
Within a management class, the specific backup and archive requirements are in copy groups. Copy groups define the specific storage management attributes that describe how the server manages backed up or archived data. Copy groups include both backup copy groups and archive copy groups. A management class can have one backup copy group, one archive copy group, both, or neither.
A backup copy group contains attributes that are used during the backup process to determine:
It also contains attributes to manage the backup versions of your files on the server. These attributes control:
An archive copy group contains attributes that control:
When the server is unable to rebind a file to an appropriate management class, the server uses one of two values to determine the number of days to retain the file. If it is a backup version, the server uses backup retention grace period. Archive copies are never rebound because each archive operation creates a different archive copy. Archive copies remain bound to the management class name specified when the user archived them. If the management class to which an archive copy is bound no longer exists or no longer contains an archive copy group, the server uses the default management class. If you later change or replace the default management class, the server uses the updated default management class to manage the archive copy. If the default management class does not contain an archive copy group, the server uses the archive retention grace period specified for the policy domain. For more information about grace periods, see Using a retention grace period.
Before you select the management classes you want to use, click View policy information from the Utilities menu. The Display policy information window is displayed. You can then determine which management classes are available.
The Display policy information window provides the following information:
You can also use the detail option on the query mgmtclass command to view the available management classes.
Table 43 shows the default values for the backup and archive copy
groups in the standard management class. Each attribute is discussed in
more detail immediately following the table.
Table 43. Default values in the standard management class
Attribute | Backup default | Archive default |
---|---|---|
Copy group name | Standard | Standard |
Copy type | Backup | Archive |
Copy frequency | 0 days | CMD (Command) |
Versions data exists | Two versions | Does not apply |
Versions data deleted | One version | Does not apply |
Retain extra versions | 30 days | Does not apply |
Retain only version | 60 days | Does not apply |
Copy serialization | Shared static | Shared static |
Copy mode | Modified | Absolute |
Copy destination | Backuppool | Archivepool |
Retain versions | Does not apply | 365 days |
The name of the copy group. The default value for both backup and archive is Standard.
The type of copy group. The value for backup is always Backup, and the value for archive is always Archive.
Copy frequency is the minimum number of days that must elapse between successive incremental backups. Use this attribute during a full incremental backup.
Copy frequency works with the mode parameter. For example, if frequency is zero (0) and mode is modified, a file or directory is backed up only if it changed since the last incremental backup. If frequency is zero (0) and mode is absolute, a file is backed up every time you run an incremental backup against it. This attribute is not checked for selective backups.
For archive copy groups, copy frequency is always CMD (command). There is no restriction on how often you archive a file.
The Versions Data Exists attribute specifies the maximum number of different backup versions retained for files and directories currently on your workstation. If you select a management class that permits more than one backup version, the most recent version is called the active version. All other versions are called inactive versions. If the maximum number of versions permitted is five, and you run a backup that creates a sixth version, the oldest version is deleted from server storage.
The Versions Data Deleted attribute specifies the maximum number of different backup versions retained for files and directories that you erased from your workstation. This parameter is ignored as long as the file or directory remains on your workstation.
If you erase the file or directory, the next time you run an incremental backup, the active backup version is changed to inactive and the oldest versions are erased that exceed the number specified by this parameter.
The expiration date for the remaining versions is based on the retain extra versions and retain only version parameters.
The Retain Extra Versions attribute specifies how many days all but the most recent backup version is retained. The most recent version is the active version, and active versions are never erased. If Nolimit is specified, then extra versions are kept until the number of backup versions exceeds the versions data exists or versions data deleted parameter settings. In this case, the oldest extra version is deleted immediately.
The Retain Only Version attribute specifies the number of days the last remaining inactive version of a file or directory is retained. If Nolimit is specified, the last version is retained indefinitely.
This parameter goes into effect during the next incremental backup after a file is deleted from the client machine. Any subsequent updates to this parameter will not affect files that are already inactive. For example: If this parameter is set to 10 days when a file is inactivated during an incremental backup, the file will be expired in 10 days.
The Copy Serialization attribute determines whether a file can be in use during a backup or archive, and what to do if it is. The value for this attribute can be one of the following:
Note: During an image backup, the static copy serialization value is no longer controlled by the server management class, but is instead controlled directly from the client, using the imagetype option. See Imagetype for more information.
Note: During an image backup, the dynamic copy serialization value is no longer controlled by the server management class, but is instead controlled directly from the client, using the imagetype option. See Imagetype for more information.
Attention: Be careful when you select a management class containing a copy group that specifies shared dynamic or dynamic for serialization backup. If you select a management class that permits a file to be backed up or archived while it is in use, the backup version or archived copy stored on the server might be a fuzzy copy. A fuzzy copy is a backup version or archived copy that does not accurately reflect what is currently in the file. It might contain some, but not all, of the changes. If that is not acceptable, select a management class that creates a backup version or archive copy only if the file does not change during a backup or archive.
If you restore or retrieve a file that contains a fuzzy copy, the file might not be usable. You should not use dynamic or shared dymamic serialization to back up files, unless you are absolutely certain that a restore of a fuzzy copy will be usable.
The Copy Mode attribute determines whether a file or directory is considered for incremental backup regardless of whether it changed or not since the last backup. Tivoli Storage Manager does not check the mode for selective backups. The value for this parameter can be one of the following:
Names the destination where backups or archives are stored. The destination can be either a storage pool of disk devices or a storage pool of devices that support removable media, such as tape.
Specifies the number of days an archived file remains in storage. When the specified number of days elapse for an archived copy of a file, it is deleted from server storage.
If the default management class meets the backup and archive requirements for all the files on your workstation, it is not necessary to take any action to associate your files with that management class. This is done automatically when you back up or archive your files.
When selecting a different management class for your files, consider these questions:
If you attempt to back up a file associated with a management class that does not contain a backup copy group, the file is not backed up.
You cannot archive a file associated with a management class that does not contain an archive copy group.
Mode and frequency work together to control how often a file is backed up when you use incremental backup. Tivoli Storage Manager does not check those attributes for selective backup.
If serialization is shared dynamic or dynamic, you might get fuzzy backups or archive copies. Verify that this is acceptable. For example, you might want to use shared dynamic or dynamic serialization for a file to which log records are continuously added. If you used static or shared static serialization, the file might never back up because it is constantly in use. With shared dynamic or dynamic serialization, the file is backed up, but the backup version of the file might contain a truncated message. Do not use shared dynamic or dynamic serialization for a file if it is very important that the backup version or archive copy contain all changes.
A management class defines when your files are included in a backup, how long they are kept on the server, and how many versions of the file the server should keep. The server administrator selects a default management class. You can specify your own management class to override the default management class.
To assign a management class other than the default to directories, use the dirmc option in your client system options file (dsm.sys). See Dirmc for more information.
You can assign a management class for a file or file group by using an include statement in your client systems options (dsm.sys) file or the include-exclude file specified by the inclexcl option. Management class names are not case-sensitive. For example, to associate all the files in the costs directory with a management class named budget, enter:
include /home/jones/costs/* budget
To specify a management class named managall to use for all files to which you do not explicitly assign a management class, enter:
include * managall
The example below demonstrates how to use a management class:
exclude /.../*.sno include /home/winter/.../*.ice mcweekly include /home/winter/december/*.ice mcdaily include /home/winter/january/*.ice mcmonthly include /home/winter/winter/white.sno
Processing follows these steps:
To specify your own default management class for files that are not explicitly included, specify:
include * mgmt_class_name
as the first include or exclude option defined. See Include options for more information about the include option.
When you archive a file using the graphical user interface, you can select a different management class to override the management class assigned to the file.
When you archive a file, you can override the assigned management class using the graphical user interface (GUI), or by using the archmc option on the archive command. Overriding the management class using the GUI is equivalent to using the archmc option on the archive command. To use the GUI, press the Options button on the archive tree to override the management class and select a different management class. For example, to associate the file, /home/jones/budget.jan, with the management class ret2yrs, you would enter:
dsmc archive -archmc=ret2yrs /home/jones/budget.jan
Note: Do not use management classes that contain an attribute of retention initiation = event. Otherwise, the archive will fail.
If the management class in your active policy set containing the longest retention period meets your backup requirements for directories, it is not necessary to take any action to associate directories with that management class. Tivoli Storage Manager does it automatically when it backs up your directories.
If the default management class does not meet your requirements, select a management class with an adequate retention period specified on the retain only version parameter. You should keep directories at least as long as you keep the files associated with those directories.
For backup directories, you can assign a management class with an include statement, the dirmc option, or through the Tivoli Storage Manager GUI. If you do not specify a management class, Tivoli Storage Manager uses the management class in the active policy set specifying the longest retention period. See Include options and Dirmc for more information.
For archive directories, you can specify a management class with an include.archive statement, the archmc option, or through the Tivoli Storage Manager GUI. If you do not specify a management class, the server assigns the default management class to the archived directory. If the default management class has no archive copy group, the server assigns the management class that currently has the archive copy group with the shortest retention time. See Include options and Archmc for more information about the dirmc option.
Binding associates a file with a management class. When you back up a file for the first time, Tivoli Storage Manager binds it to either the default management class or the management class specified in your include-exclude list. In later full incremental backups of the same file, if you change the management class, both active and inactive versions are bound again to the new management class. However, with selective backup and incremental-by-date backups, the new backups are bound to the new management class, but previous backup versions remain bound to the original management class.
If the backup copy group for the management class specifies keeping multiple backup versions of the file, and you request multiple backups, the server always has one active backup version (the current version) and one or more inactive backup versions of the file. All backup versions of a file are bound to the same management class and are managed based on the attributes in the backup copy group.
When you archive a file for the first time, Tivoli Storage Manager binds it to the default management class, to the management class specified in your include-exclude list, or to a management class you specify when modifying your archive options during an archive.
Archived files are never rebound to a different management class. If you change the management class for a file using the an include.archive statement, the archmc option, or through the Tivoli Storage Manager GUI, any previous copies of the file that you archived remain bound to the management class specified when you archived them. expire before any file beneath it.
Backups of files are bound again to a different management class in the following conditions. In each condition, the files (active and inactive) are not bound again until the next backup.
Tivoli Storage Manager also provides a backup retention grace period and an archive retention grace period to help protect your backup and archive data when it is unable to rebind a file to an appropriate management class. The backup retention grace period is used when:
The backup retention grace period, defined in your policy domain, starts when you run an incremental backup. The default is 30 days. However, your administrator can lengthen or shorten this period.
When Tivoli Storage Manager manages a file using the backup retention grace period, it does not create any new backup versions of the file. All existing backup versions of the file expire 30 days (or the number of days specified in your policy domain) from the day they are marked inactive.
Archive copies are never rebound because each archive operation creates a different archive copy. Archive copies remain bound to the management class name specified when the user archived them. If the management class to which an archive copy is bound no longer exists or no longer contains an archive copy group, the server uses the default management class. If you later change or replace the default management class, the server uses the updated default management class to manage the archive copy. If the default management class does not contain an archive copy group, the server uses the archive retention grace period specified for the policy domain.