Storage management policies are rules that your ADSM policy administrator defines to tell ADSM how to manage backups and archives, based on the needs of users and the business. If you have the ADSM HSM client installed, your administrator also defines rules that determine whether files are eligible for migration from your local file systems to ADSM storage.
For backup and archive, policies determine:
This section first explains more about storage management policies. Then, it shows you how to display what policies are available to you. Next, you can read about how to choose the best policies for your files and directories. And finally, this section explains some concepts about how ADSM associates your data with policies.
Storage management policies have several components, as described by the following terms:
If you have the ADSM HSM client installed, a management class can also contain space management attributes that determine whether files are eligible for migration and where they are stored. For information about space management attributes, see Using the UNIX HSM Clients
Most of the work you do with storage management policies is with management classes.
An ADSM administrator uses policy domains to manage a group of client nodes in a logical way. For example, a domain could consist of the following clients:
ADSM includes a policy domain named STANDARD. Initially, your client node is probably associated with that policy domain. However, your ADSM administrator can define additional policy domains if there are groups of users that have unique backup and archive requirements.
Each policy domain can hold numerous policy sets. Only one of these policy sets can be active at a time, called the active policy set. Each policy set contains a default management class and any number of additional management classes.
A management class contains the specific requirements for backing up and archiving data. If you have the ADSM HSM client installed, it can also contain specific requirements for migrating files to ADSM storage.
An ADSM administrator can establish separate management classes to meet the backup and archive requirements for different kinds of data, such as:
Each file and directory that you back up and each file that you archive must be associated with a management class. You are responsible for associating files and directories with appropriate management classes. If you do not associate a file with a management class, ADSM uses the default management class in the active policy set. If you do not specify a management class for directories, ADSM uses the management class in the active policy set that specifies the longest retention period.
You associate files with management classes by using INCLUDE options in your include-exclude options file. See "Choosing a Management Class for Files" for more information. To associate directories with a management class, you use the DIRMC option in your client system options file. See "Choosing a Management Class for Directories" for more information.
Within a management class, the specific backup and archive requirements are in copy groups. There are two kinds of copy groups: 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 ADSM uses during the backup process to determine the following:
It also contains attributes that ADSM uses to manage the backup versions of your files on the server. Those attributes control the following:
An archive copy group contains attributes that control the following:
Before you choose the management classes you want to use, you need to see which ones are available by clicking on the Utilities menu; Display policy information item. The information is displayed in the Display Policy Information window.
You can also use the QUERY MGMTCLASS command with the DETAIL option to see the available management classes.
ADSM displays the following information in this window:
For policy information, you see this information:
For more information on grace periods, see "Using a Retention Grace Period".
For management class information, you see this information:
If you have the ADSM HSM client installed, the management class information can also include:
Attention |
---|
If this attribute is set to Yes, ADSM checks for a backup version only on your migration server. If your backup-archive server and migration server are not the same, setting this option to Yes prohibits migration. |
You will see information for both backup and archive copy groups:
Copy frequency works with the copy mode parameter that is described later. For example, if copy frequency is 0, and copy mode is modified, a file or directory is backed up only if it has been changed since the last incremental backup.
If copy frequency is 0, and copy mode is absolute, a file is backed up every time you run an incremental backup against it.
ADSM does not check this attribute for selective backups.
For archive copy groups, the copy frequency is always CMD (command), that is, there is no restriction on how often you can archive a file.
If you select a management class that allows more than one backup version, the most current version is called the active version. All other versions are called inactive versions.
If the maximum number of versions allowed is 5, and you run a backup that creates a sixth version, ADSM deletes the oldest version from server storage.
If you erase the file or directory, the next time you run an incremental backup, ADSM changes the active backup version to inactive and erases the oldest versions that are in excess of 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 described later.
If Nolimit is specified, extra backup versions are deleted based on the Versions Data Exists or Versions Data Deleted parameters.
If Nolimit is specified, the last version is retained forever.
When the specified number of days elapse for an archived copy of a file, ADSM deletes it from ADSM storage.
For archive copy groups, the copy mode is always absolute, which indicates that a file is archived regardless of whether it has changed since the last archive request.
ADSM includes a default management class named STANDARD. Figure 3 shows the default values for the backup and archive copy groups in this
management class.
Figure 3. 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 |
Versions Data Exists | 2 versions | N/A |
Versions Data Deleted | 1 version | N/A |
Retain Extra Versions | 30 days | N/A |
Retain Only Version | 60 days | N/A |
Retain Version | N/A | 365 days |
Copy Serialization | shared static | shared static |
Copy Mode | modified | absolute |
Copy Destination | BACKUPPOOL | ARCHIVEPOOL |
Figure 4 shows the default values for space management attributes in the STANDARD
management class if you have the ADSM HSM client installed.
Figure 4. Default Values for Space Management Attributes
Attribute | Default |
---|---|
Space Management Technique | None |
Auto Migrate on Non-Usage | 0 |
Backup Required Before Migration | Yes |
Destination for Migrated Files | SPACEMGPOOL |
If the default management class meets the backup, archive, and space management requirements for all the files on your workstation, you do not need to take any action to associate your files with that management class. ADSM does that automatically when your files are backed up, archived, or migrated.
To assign a management class other than the default to a file or group of files, use an INCLUDE statement in your include-exclude options file. For example, to associate all the files in the /home/jones/costs directory with a management class named BUDGET use the following include statement:
INCLUDE /home/jones/costs/* budget
Management class names are not case sensitive.
To specify a management class to be used for all files to which you do not explicitly assign a management class, use the following include statement as the first statement in your include-exclude options file:
INCLUDE * managall
where managall is the name of an available management class. For more information about using the include-exclude options file, see "Using Management Classes with the Include Option".
When you archive a file, you can choose to override the assigned management class. When using the graphical user interface, ADSM presents a window that allows you to select a different management class.
When using the ARCHIVE command, you can use the ARCHMC option to specify a different management class. For example, to associate the file /home/jones/budget.jan with the management class RET2YRS, you specify the following:
dsmc archive -archmc=ret2yrs /home/jones/budget.jan
For more information about ARCHMC, see Archive.
If you need to choose a different management class for some of your files, consider the following questions.
If you attempt to back up a file that is associated with a management class that does not contain a backup copy group, the file is not backed up.
If you attempt to archive a file that is associated with a management class that does not contain an archive copy group, the file is not archived.
Copy mode and copy frequency work together to control how often a file is backed up when you use incremental backup. ADSM does not check those attributes for selective backup.
If copy serialization is shared dynamic or dynamic, you might get fuzzy backups or archive copies. Be sure you understand whether that is acceptable.
For example, you might want to use shared dynamic or dynamic for a file where log records are continuously added to it. If you used static or shared static, the file might not be backed up at all because it is constantly in use. With shared dynamic or dynamic, the file would be backed up, but the backup version of the file might contain a truncated message.
However, you would not want to use shared dynamic or dynamic for a file if it is critical that the backup version or archive copy contain all changes. That is probably the case for most of your files.
Note: | If you have the ADSM HSM client installed, and you want a file to be eligible for migration, you must assign the file a management class that also contains the appropriate space management attributes. |
If the management class in your active policy set that contains the longest retention period meets your backup requirements for directories, you do not need to take any action to associate directories with that management class. ADSM does it automatically when it backs up your directories.
If that default management class does not meet your requirements, be sure to choose a management class with an adequate retention period specified for Retain Only Version. You want to be sure that ADSM keeps directories at least as long as it keeps the files associated with those directories.
To assign a management class other than the default to directories, you use the DIRMC option in your client system options file. For example, to assign a management class named DIRECT1 to your directories, you would enter:
DIRMC DIRECT1
For more information about using DIRMC, see Dirmc.
When you back up a file for the first time, ADSM binds it to either the default management class or the management class specified for the file in your include-exclude options file. Binding is the term for associating a file with a management class.
If the backup copy group for the management class instructs ADSM to keep multiple backup versions of the file, and you request multiple backups, the server always has one active backup version (the most current version) and one or more inactive backup versions of the file. All the 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, ADSM binds it to the default management class, to the management class specified for the file in your include-exclude options file, or to a management class you specify.
There are several instances when backup versions of a file can be rebound to a different management class. Archived files are never rebound to a different management class. If you change the management class for a file, any previous copies of the file that you have archived remain bound to the management class specified when you archived them.
Backups of files are rebound to a different management class in the following cases. In each case, the files (active and inactive) are not rebound until the next backup.
ADSM continues to manage the backups based on the old management class until you run another backup.
ADSM uses the default management class to manage the backup versions when you back up the file again.
ADSM uses the default management class for the new policy domain to manage the backup versions.
ADSM also provides a backup retention grace period and an archive retention grace period that it uses to help protect your backup and archive data when it is unable to rebind a file to an appropriate management class.
For example, ADSM uses the backup retention grace period in these cases:
ADSM begins using the backup retention grace period when you run an incremental backup.
The backup retention grace period is defined in your policy domain. The default is 30 days. However, your ADSM administrator can choose to change that value to a longer or shorter period.
After ADSM begins managing 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.
For archived files, if the management class to which a file is bound no longer exists, and the default management class does not contain an archive copy group, ADSM uses the archive retention grace period defined in your policy domain. The default retention period is 60 days. Your ADSM administrator can choose to change that value to a longer or shorter period.