Policy management describes how to treat the customer data and rules to store the customer data.
It can also be defined as set of rules associated to group of nodes is called as policy management.
Hierarchy of policy management is as below:
1) Policy Domain
2) Policy Set
3) Management Class
4) Copy Group
a) Backup
b) Archive
POLICY DOMAIN:
Policy domain is set or group of nodes is called as policy domain. Policy domain contains policy set and in each policy domain we can define N no. of policy sets but at a time only policy set can be activated.
Def dom domainname
POLICY SET:
Policy set contains Management class. And under each policy set we can define N No. of Management classes.
Def pol domainname policysetname
Management Class:
Management class contains Copygroup. And we can have N No. of Management classes under each policy set but one management class has to be assigned as default management class.
Def mgmt domainname policysetname mgmtclassname
MANAGEMENT CLASS BINDING:
As I mentioned earlier in this policy management we can define multiple number of management classes under each policy domain and policy set but we have to assign one management class as default mgmt class. When we are adding clients or nodes to Domain all the nodes will be added to default mgmt class only and if want to assign a node to different mgmt class other than default mgmt class then we need to go client configuration file called dsm.opt file which is present in client machine and enter a command .
include* managementclass name
Ex: include*mgmt1
This mechanism of assigning nodes or client machines to other mgmt classes other than default mgmt class is known as mgmt class Binding.
COPY GROUP:
Copy group is the place in policy management where we have to define the backup and archive copy group. The client data which is being backed up will moves to backup copygroup.
· And the data which is being archived will move to Archive copygroup.
PARAMETERS UNDER BACKUP COPYGROUP
1) VERSION EXIST: (verexist)
This parameter defines how many no. of versions of the backup data of frequently modifies file have to be stored. If we mention versionexist=6 then 6 versions of the file which is being modified will be stored in the TSM storage pool and once the 7 version of the file is backed up automatically the first version the file will be deleted. The expired file will be deleted from the TSM server once the expiration inventory process is executed in TSM Server. The latest version of the file is known as active version and all the previous versions is known as inactive versions.
2) VERSION DELETE: (verdelete)
This parameter defines how no. of versions of the file has to be stored once the actual file is deleted from the client machine.
If we mention versiondelete=4 then once the actual file is deleted from the client machine then 4 recent versions of the file or object will be stored in the TSM Server and the remaining versions will be deleted once the expiration inventory process is executed.
3) Retention exist: ( Retexist)
This parameter defines how many no. of days the inactive versions of a unmodified file have to be stored in the TSM server.
If we mention Retexist=60. Then if file is not been modified for 60 days then all the inactive versions of the file will be deleted and only the active version of the file will be stored.
4) RETENTION ONLY: (RETONLY)
This parameter defines how many no. of days the versions of a file to be saved from the time the actual file is deleted from the client machine.
If we mention retonly=120 then the TSM server will maintain the versions of the file for 120 days which is already been deleted from the client machine. And on 121st day all the versions of the file will be deleted from the TSM Server.
5) RETENSION VERSION: ( RETVER)
This parameter is defined under archive copygroup. This defines how many no. of days the archive data has to be stored. If we mention retver=3600 then the archived data will be stored in TSM Server for 3600 days and on 3601st day the data will get deleted from the TSM Server.
6) SERIALIZATION:
This parameter is used in backup copygroup. This parameter is applicable for open files in the client machine. Open files are those files which are being used or processed by any user or application. While taking backup of the client machine then TSM server treats these open files in 4 different ways. They are:
a) Static:
In this mechanism while backup is running if any of the file is open then the TSM Server will skip the file from Backup and an error will be raised mentioning that the supposed file is not backed up due to that file was open at the time of backup.
b) Shared static:
In this mechanism TSM Server tries to access the file for 4 times to take the backup of the file at regular intervals and the interval time between each attempt will be default taken by TSM server itself depends on the data to be backed up. If during the fourth attempt also the file is still open then the TSM Server skips the file from backup and raises an error mentioning that the file was open during the backup schedule so that it is not backed up.
In real-time we mention the serialization parameter as Shared Static.
c) DYNAMIC:
In this mechanism if a file is in open state during the backup schedule then also the TSM Server will take the backup of the file @ the first time only regardless of the file being used or not.
d) SHARED DYNAMIC:
In this mechanism if a file is in open state during the backup schedule then the TSM Server tries to access the file for 4 times with regular intervals and if the fourth time also file is still open the @ the fourth time TSM Server will take the backup the file regardless of the file is still open or not.
VALIDATING AND ACTIVATION OF POLICY SET
Ø Once all the parameters are defined under the policy management we have to validate the policy set and then activate the policy set.
Ø Validating the policy set is nothing but TSM Server verifies the policy mgmt hierarchy is defined in correct order or not.
Ø Once the validation of policy set was done we can activate the policy set.
It can also be defined as set of rules associated to group of nodes is called as policy management.
Hierarchy of policy management is as below:
1) Policy Domain
2) Policy Set
3) Management Class
4) Copy Group
a) Backup
b) Archive
POLICY DOMAIN:
Policy domain is set or group of nodes is called as policy domain. Policy domain contains policy set and in each policy domain we can define N no. of policy sets but at a time only policy set can be activated.
Def dom domainname
POLICY SET:
Policy set contains Management class. And under each policy set we can define N No. of Management classes.
Def pol domainname policysetname
Management Class:
Management class contains Copygroup. And we can have N No. of Management classes under each policy set but one management class has to be assigned as default management class.
Def mgmt domainname policysetname mgmtclassname
MANAGEMENT CLASS BINDING:
As I mentioned earlier in this policy management we can define multiple number of management classes under each policy domain and policy set but we have to assign one management class as default mgmt class. When we are adding clients or nodes to Domain all the nodes will be added to default mgmt class only and if want to assign a node to different mgmt class other than default mgmt class then we need to go client configuration file called dsm.opt file which is present in client machine and enter a command .
include* managementclass name
Ex: include*mgmt1
This mechanism of assigning nodes or client machines to other mgmt classes other than default mgmt class is known as mgmt class Binding.
COPY GROUP:
Copy group is the place in policy management where we have to define the backup and archive copy group. The client data which is being backed up will moves to backup copygroup.
· And the data which is being archived will move to Archive copygroup.
PARAMETERS UNDER BACKUP COPYGROUP
1) VERSION EXIST: (verexist)
This parameter defines how many no. of versions of the backup data of frequently modifies file have to be stored. If we mention versionexist=6 then 6 versions of the file which is being modified will be stored in the TSM storage pool and once the 7 version of the file is backed up automatically the first version the file will be deleted. The expired file will be deleted from the TSM server once the expiration inventory process is executed in TSM Server. The latest version of the file is known as active version and all the previous versions is known as inactive versions.
2) VERSION DELETE: (verdelete)
This parameter defines how no. of versions of the file has to be stored once the actual file is deleted from the client machine.
If we mention versiondelete=4 then once the actual file is deleted from the client machine then 4 recent versions of the file or object will be stored in the TSM Server and the remaining versions will be deleted once the expiration inventory process is executed.
3) Retention exist: ( Retexist)
This parameter defines how many no. of days the inactive versions of a unmodified file have to be stored in the TSM server.
If we mention Retexist=60. Then if file is not been modified for 60 days then all the inactive versions of the file will be deleted and only the active version of the file will be stored.
4) RETENTION ONLY: (RETONLY)
This parameter defines how many no. of days the versions of a file to be saved from the time the actual file is deleted from the client machine.
If we mention retonly=120 then the TSM server will maintain the versions of the file for 120 days which is already been deleted from the client machine. And on 121st day all the versions of the file will be deleted from the TSM Server.
5) RETENSION VERSION: ( RETVER)
This parameter is defined under archive copygroup. This defines how many no. of days the archive data has to be stored. If we mention retver=3600 then the archived data will be stored in TSM Server for 3600 days and on 3601st day the data will get deleted from the TSM Server.
6) SERIALIZATION:
This parameter is used in backup copygroup. This parameter is applicable for open files in the client machine. Open files are those files which are being used or processed by any user or application. While taking backup of the client machine then TSM server treats these open files in 4 different ways. They are:
a) Static:
In this mechanism while backup is running if any of the file is open then the TSM Server will skip the file from Backup and an error will be raised mentioning that the supposed file is not backed up due to that file was open at the time of backup.
b) Shared static:
In this mechanism TSM Server tries to access the file for 4 times to take the backup of the file at regular intervals and the interval time between each attempt will be default taken by TSM server itself depends on the data to be backed up. If during the fourth attempt also the file is still open then the TSM Server skips the file from backup and raises an error mentioning that the file was open during the backup schedule so that it is not backed up.
In real-time we mention the serialization parameter as Shared Static.
c) DYNAMIC:
In this mechanism if a file is in open state during the backup schedule then also the TSM Server will take the backup of the file @ the first time only regardless of the file being used or not.
d) SHARED DYNAMIC:
In this mechanism if a file is in open state during the backup schedule then the TSM Server tries to access the file for 4 times with regular intervals and if the fourth time also file is still open the @ the fourth time TSM Server will take the backup the file regardless of the file is still open or not.
VALIDATING AND ACTIVATION OF POLICY SET
Ø Once all the parameters are defined under the policy management we have to validate the policy set and then activate the policy set.
Ø Validating the policy set is nothing but TSM Server verifies the policy mgmt hierarchy is defined in correct order or not.
Ø Once the validation of policy set was done we can activate the policy set.