| 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 may need more flexibility in your policies than the standard ADSM policy provides. For example, you may want to change the backup copy group parameters, to enable clients to restore backed-up files to a specific point in time (see "Special Considerations: Enabling Point-in-Time Restore for Clients" for more information).
You can create your own policies in either of two ways: you can
define the parts of a policy and specify each attribute, or you can copy
existing policy parts and update only those attributes that you want to
change. 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: | You create: |
|---|---|
| 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 |
The sections that follow describe the tasks involved in creating new policies for your installation:
To help users take advantage of ADSM, you can set up the policy environment by doing the following:
For information on how to create an include-exclude list, see the user's publication for the appropriate client.
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, STANDARD and SUMMER. The policy set named STANDARD is active. Only one policy set can be active at a time. When a policy set is activated, the server makes a copy of the policy set and names it ACTIVE.
The ACTIVE policy set contains three management classes: ENGINEERING, MCENG, and MCENGBK3. The default management class is MCENG.
Figure 39. An Example of Policy Objects Defined for an Engineering Department
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 ADSM 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:
A business with seasonal employees needs two policy sets. During most of the year, most users would use the STANDARD policy set. During the summer, it would activate the SUMMER policy set to provide new management classes for users who are seasonal employees. To create the SUMMER policy set in the STANDARD policy domain, the business would perform the following steps:
copy policyset standard standard summer
| Note: | When you copy an existing policy set, you also copy any associated management classes and copy groups. |
update policyset standard summer description='Policy set activated during summer for STANDARD domain'
When you define or update a management class, specify:
| Note: | You cannot specify a copy storage pool as a destination. |
Create a new management class containing a backup copy group and an archive copy group:
copy mgmtclass engpoldom standard standard mceng
The server copies the management class description, standard backup copy group, and standard archive copy group to MCENG.
update mgmtclass engpoldom standard mceng description='Engineering Mgmt Class - Backup & Archive Copy Groups'
To define or update a backup copy group on the graphical user interface or command line, specify:
| Note: | You cannot specify a copy storage pool. |
For most files, set serialization to either static or shared static to prevent the server from backing up a file while it is being modified.
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.
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 backed up because they are constantly in use. With shared dynamic or dynamic, the log files are backed up. However, the backup version may contain a truncated message.
| 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, ADSM does not back up the file. |
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. 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 users want to retain multiple backup versions. If the mode is set to absolute, users may 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 OS/2 files with extended attributes are backed up, because ADSM does not detect changes to the extended attributes.
When you set the mode to absolute, set 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.
If users 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. For example, in Figure 40, the most current version of REPORT.TXT was created on Friday at 3 p.m. There are two inactive versions of REPORT.TXT.
When the maximum number of backup versions is exceeded, the oldest version expires and the server deletes it the next time expiration processing runs. For example, if the maximum number of versions allowed for MEMO.DAT is three, and a user runs a backup process that creates a fourth version, the oldest version expires. In this example, the backup version created on Thursday at 8:05 a.m. expires.
How many inactive versions ADSM keeps is also related to the parameter for how long inactive versions are kept (Retain Extra Versions). Inactive versions can expire when their age exceeds the value specified for retaining extra versions, even when the number of versions is not exceeded.
To enable client nodes to restore files to a specific point in time, set the value for Versions Data Exists to 9999. Setting the value this high ensures that versions are retained according to the Retain Extra Versions parameter for the copy group. See "Special Considerations: Enabling Point-in-Time Restore for Clients" for more information.
Figure 40. Example of Active and Inactive Versions of Backed Up Files
If users erase a file or directory from their client nodes, then the next time a full incremental backup is run, the server changes the active backup version to inactive. The oldest versions that are more than the number specified by this parameter then expire, and the server deletes them the next time expiration processing runs.
The expiration date for the remaining versions is based on the Retain Extra Versions and Retain Only Version parameters.
To enable client nodes to restore files to a specific point in time, set the value for Versions Data Deleted to 9999. Setting the value this high ensures that versions are retained according to the Retain Extra Versions parameter for the copy group. See "Special Considerations: Enabling Point-in-Time Restore for Clients" for more information.
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 9999. 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 "Special Considerations: Enabling 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 enable clients to restore backed-up files to a specific point in time, you must set up the backup copy group differently from the STANDARD. The Versions Data Exists, Versions Data Deleted, and Retain Extra Versions parameters work together to determine over what time period a client can perform a point-in-time restore operation.
For example, you decide to ensure that clients can choose to restore files from anytime in the previous 60 days. In the backup copy group, set the Retain Extra Versions parameter to 60 days. More than one backup version of a file may be stored per day if clients perform selective backups or if clients perform incremental backups more than once a day. The Versions Data Exists parameter and the Versions Data Deleted parameter control how many of these versions are kept by ADSM. To ensure that any number of backup versions are kept for the required 60 days, set both the Versions Data Exists parameter and the Versions Data Deleted parameter to 9999. This means that backup versions are essentially kept based on how old the versions are, instead of how many backup versions of the same file exist.
Keeping backed-up versions of files long enough to allow clients to restore their data to a point in time can mean increased resource costs. Requirements for ADSM storage increase because more file versions are kept, and the size of the ADSM database increases to track all the file versions. Because of these increased costs, you may want to choose carefully which clients can use the policy that allows for point-in-time restore operations.
Clients need to run full incremental backup operations frequently enough so that ADSM can detect files that have been deleted on the client file system. Only a full incremental backup can detect whether files have been deleted since the last backup. If full incremental backup is not done often enough, clients who restore to a specific time may find that many files that had actually been deleted from the workstation get restored. As a result, a client's file system may run out of space during a restore process.
To define or update an archive copy group on the graphical user 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.
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.
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.
| 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, ADSM does not back up the file. |
An ADSM server (a source server) can be registered as a client to another ADSM server (the target server). Data stored by the source server appears as archived files on the target server. The source server is registered to a policy domain on the target server, and uses the default management class for that policy domain. In the default management class, the destination for the archive copy group determines where the target server stores data for the source server. Other policy specifications, such as how long to retain the data, do not apply to data stored for a source server. See Chapter 4. "Storing Data on Another Server" for more information.
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 your policy sets and the management classes that they contain, you must assign a default management class for each 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 SUMMER policy set in the STANDARD policy domain, enter:
assign defmgmtclass standard summer standard
The STANDARD management class was copied from the STANDARD policy set to the SUMMER 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 your policy sets and assigned management classes to them, you can validate those policy sets and activate one 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 specified 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 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:
After a policy set has been activated, 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. You cannot update the ACTIVE policy set. To change its contents, you must do the following:
Validating and activating the SUMMER policy set in the STANDARD policy domain is a two-step process:
validate policyset standard summer
activate policyset standard summer
Files expire under the following conditions:
ADSM does not delete information about the expired files from the server database until expiration processing runs. You can run expiration processing either automatically or by command. You control automatic expiration processing by using the expiration interval option (EXPINTERVAL) in the ADSM server options file (dsmserv.opt). You can set the option through the ADSM Server Utilities or by editing the dsmserv.opt file (see ADSM Administrator's Reference).
If you use the server option to control when expiration processing occurs, ADSM 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 information about 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.
When expiration processing runs, normally ADSM sends detailed messages about policy changes made since the last time expiration processing ran. The messages are about changes you made that affect client files, such as deleting a management class or a copy group. You can reduce the number of messages about policy changes that are generated during expiration processing by using the EXPQUIET option in the server options, or the QUIET=YES parameter with the EXPIRE INVENTORY command. When you use the quiet option or parameter, ADSM 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 the DRM Feature: If your server is licensed for the DRM feature, 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.