Associating objects with management classes
A primary feature of IBM® Storage Protect is the use of policies (management classes) to define how objects are stored and managed in IBM Storage Protect storage. An object is associated with a management class when the object is backed up or archived.
This management class determines:
- How many versions of the object are kept if backed up
- How long to keep archive copies
- Where to insert the object in the storage hierarchy on the server
Management classes consist of both backup copy groups and archive copy groups. A copy group is a set of attributes that define the management policies for an object that is being backed up or archived. If a backup operation is being performed, the attributes in the backup copy group apply. If an archive operation is being performed, the attributes in the archive copy group apply.
The backup or archive copy group in a particular management class can be empty or NULL. If an object is bound to the NULL backup copy group, that object cannot be backed up. If an object is bound to the NULL archive copy group, the object cannot be archived.
Because the use of a policy is a very important component of IBM Storage Protect, the API requires that all objects sent to the server are first assigned a management class by using the dsmBindMC call. With IBM Storage Protect software, you can use an include-exclude list to affect management class binding. The dsmBindMC call uses the current Include-Exclude list to perform management class binding.
Include statements can associate a specific management class with a backup or archive object. Exclude statements can prevent objects from being backed up but not from being archived.
The API requires that dsmBindMC is called before you back up or archive an object. The dsmBindMC call returns a mcBindKey structure that contains information on management class and copy groups that are associated with the object. Check the copy group destination before proceeding with a send. When you send multiple objects in a single transaction, they must have the same copy group destination. The dsmBindMC function call returns the following information:
| Information | Description |
|---|---|
| Management Class | The name of the management class that was bound to the object. The application client can send the dsmBeginQuery call to determine all attributes of this management class. |
| Backup Copy Group | Informs you if a backup copy group exists for this management class. If a backup operation is being performed and a backup copy group does not exist, this object cannot be sent to storage. You receive an error code if you attempted to send it using the dsmSendObj call. |
| Backup Copy Destination | This field identifies the storage pool to which the data is sent. If you are performing a multiple object backup transaction, all copy destinations within that transaction must be the same. If an object has a different copy destination than previous objects in the transaction, end the current transaction and begin a new transaction before you can send the object. You receive an error code if you attempt to send objects to different copy destinations within the same transaction. |
| Archive Copy Group | Informs you if an archive copy group exists for this management class. If an archive operation is being performed and an archive copy group does not exist, this object cannot be sent to storage. You receive an error code if you attempted to send it using the dsmSendObj call. |
| Archive Copy Destination | This field identifies the storage pool to which the data are sent. If you are performing a multiple object archive transaction, all copy destinations within that transaction must be the same. If an object has a different copy destination than previous objects in the transaction, end the current transaction and begin a new transaction before you send the object. You receive an error code if you attempt to send objects to different copy destinations within the same transaction. |
Backup copies of an object can be rebound to a different management class if a subsequent back up with the same object name is done that uses a management class different than the original. For example, if you back up ObjectA and bind it to Mgmtclass1, and later you back up ObjectA and bind it to Mgmtclass2, the most current backup rebinds any inactive copies to Mgmtclass2. The parameters defined in Mgmtclass2 would now control all copies. However the data does not move if the destination is different.
You can also rebind backup copies to a different management class using the dsmUpdateObj or dsmUpdateObjEx call with the DSM_BACKUPD_MC action.