Understanding TSM Policy Management Hierarchy


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:
  • 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
IBM Tivoli Storage Manager provides a standard policy that sets rules to provide a basic amount of protection for data on workstations. If this standard policy meets your needs, you can begin using Tivoli Storage Manager immediately. The server process of expiration is one way that the server enforces policies that you define. 

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.


TSM Policy Sructure by IBM

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
Policy Set

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 ?

Backup Copy Goup

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
Archive Copy Group

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
  • 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:
With default STANDARD policy settings up-to two backup versions of a file on the client’s system are retained in server storage. The most recent backup version is retained for as long as the original file is on the client file system. All other versions are retained for up to 30 days after they become inactive.One backup version of a file that has been deleted from the client’s system is retained in server storage for 60 days. An archive copy is kept for up to 365 days.

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.
Policy determines how many inactive versions of files the server keeps, and for how long. When files exceed the criteria, the files expire. Expiration processing can then remove the files from the server database.


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).
Also Read: Different types of Image Backups
You cannot directly modify the ACTIVE policy set. If you want to make a small change to the ACTIVE policy set, copy the policy to modify it and follow the steps here
  • 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.
Example:


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>




What Others are Reading Now...

4 Responses to "Understanding TSM Policy Management Hierarchy"

  1. Thanks for making this clear...it was confusing to me earlier.

    ReplyDelete
  2. Thank you for your clear explanation. It helps me to understand clearly.

    ReplyDelete