Tivoli Storage Manager Policy Management are the important set of rules or instructions to TSM server & database for managing client backups in the server storage. Policies are rules that you set at the IBM Tivoli Storage Manager server to help you manage client data. Policies control how and when client data is stored, how long to be stored and when to expire. For example:
Expiration processing determines when files are no longer needed, that is, when the files are expired. For example, if you have a policy that requires only four copies of a file be kept, the fifth and oldest copy is expired. During expiration processing, the server removes entries for expired files from the database, effectively deleting the files from server storage.
Also Read: Understanding Management Class Binding and Management Class Rebinding ?
You may need more flexibility in your policies than the standard policy provides. To accommodate individual user's needs, you may fine tune the STANDARD policy, or create your own policies. Some types of clients or situations require special policy. For example, you may want to enable clients to restore backed-up files to a specific point-in-time.
Policy Domain
Policy Domain allows an TSM administrator group client nodes by the policies that govern their files and by the administrators who manage their policies. A policy domain contains one or more policy sets, but only one policy set (named ACTIVE) can be active at a time. The server uses only the ACTIVE policy set to manage files for client nodes assigned to a policy domain. You can use policy domains to
Specifies the management classes that are available to groups of users. Policy sets contain one or more management classes. You must identify one management class as the default management class. Only one policy set, the ACTIVE policy set, controls policy operations.
Associates backup and archive groups with files, and specifies if and how client node files are migrated to storage pools. A management class can contain one backup or archive copy group, both a backup and archive copy group, or no copy groups. Users can bind (that is, associate) their files to a management class through the include-exclude list.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
Backup Copy Goup
Controls the backup processing of files associated with the management class. A backup copy group determines the following
- How and when files are backed up and archived to server storage
- How space-managed files are migrated to server storage
- The number of copies of a file and the length of time copies are kept in server storage
Expiration processing determines when files are no longer needed, that is, when the files are expired. For example, if you have a policy that requires only four copies of a file be kept, the fifth and oldest copy is expired. During expiration processing, the server removes entries for expired files from the database, effectively deleting the files from server storage.
Also Read: Understanding Management Class Binding and Management Class Rebinding ?
You may need more flexibility in your policies than the standard policy provides. To accommodate individual user's needs, you may fine tune the STANDARD policy, or create your own policies. Some types of clients or situations require special policy. For example, you may want to enable clients to restore backed-up files to a specific point-in-time.
Tivoli Storage Manager Policy Structure
TSM administrators use IBM Tivoli Storage Manager policy to specify how files are backed up, archived, migrated from client node storage, and managed in server storage. TSM policy structure consists of Policy Domain, Policy Set, Management Class. Each management class consists of Copy group and Archive group settings as shown in the below figure.Policy Domain
Policy Domain allows an TSM administrator group client nodes by the policies that govern their files and by the administrators who manage their policies. A policy domain contains one or more policy sets, but only one policy set (named ACTIVE) can be active at a time. The server uses only the ACTIVE policy set to manage files for client nodes assigned to a policy domain. You can use policy domains to
- Group client nodes with similar file management requirements
- Provide different default policies for different groups of clients
- Direct files from different groups of clients to different storage hierarchies based on need (different file destinations with different storage characteristics)
- Restrict the number of management classes to which clients have access
Specifies the management classes that are available to groups of users. Policy sets contain one or more management classes. You must identify one management class as the default management class. Only one policy set, the ACTIVE policy set, controls policy operations.
Management Classes
Associates backup and archive groups with files, and specifies if and how client node files are migrated to storage pools. A management class can contain one backup or archive copy group, both a backup and archive copy group, or no copy groups. Users can bind (that is, associate) their files to a management class through the include-exclude list.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
Controls the backup processing of files associated with the management class. A backup copy group determines the following
- How frequently a file can be backed up
- How to handle files that are in use during a backup
- Where the server initially stores backup versions of files and directories
- How many backup versions the server keeps of files and directories
- How long the server keeps backup versions of files and directories, see Running Expiration Processing to Delete Expired Files for details
Controls the archive processing of files associated with the management class. An archive copy group determines the following
- How to handle files that are in use during archive
- Where the server stores archived copies of files
- How long the server keeps archived copies of files, see Running Expiration Processing to Delete Expired Files for details.
Determining which policy settings are required ?
To determine the policy settings for a particular client backups you have to know these below client requirements
Also Read: Full vs Differential vs Incremental vs Progressive Incremental Backups
The server manages files based on whether the files are active or inactive. The most current backup or archived copy of a file is the active version. All other versions are called inactive versions. An active version of a file becomes inactive when
- How many backup versions do clients need?
- How long do clients need the backup versions?
- Examine the default policy to see if it meets your needs:
Also Read: Full vs Differential vs Incremental vs Progressive Incremental Backups
The server manages files based on whether the files are active or inactive. The most current backup or archived copy of a file is the active version. All other versions are called inactive versions. An active version of a file becomes inactive when
- A new backup is made
- A user deletes that file on the client node and then runs an incremental backup.
Editing or Changing Policy Settings
You can replace the ACTIVE policy set by activating another policy set. Perform the following steps- Create or modify a policy set so that it contains the policy that you want to implement.
- Create a new policy set either by defining a new policy set or by copying a policy set.
- Modify an existing policy set (it cannot be the ACTIVE policy set).
- Make any changes that you need to make to the management classes, backup copy groups, and archive copy groups in the new policy set.
- Validate the policy set.
- Activate the policy set. The contents of your new policy set becomes the ACTIVE policy set.
define domain <newdomainname>
define policyset <domainname> <newpolicyname>
define mgmtclass <domainname> <policyname> <newmgmtclassname>
update copyg <domainname> <policysetname> <mgmtclassname> vere=30 rete=30 verd=10 reto=90
validate policy <domainname> <policysetname>
activate policy <domainname> <policysetname>
Thanks for making this clear...it was confusing to me earlier.
ReplyDeleteYou are welcome Kuljeet
ReplyDeleteNice explanation:)
ReplyDeleteThank you for your clear explanation. It helps me to understand clearly.
ReplyDelete