TSM 6.3 Retention Trigger

brsrylmz

Active Newcomer
Joined
Jul 29, 2014
Messages
41
Reaction score
0
Points
0
PREDATAR Control23

Hello,

We are using TSM 6.3.4 on Windows server. I have two question.

+ I changed retention policy for example i changed Versions Data Exists parameter 3 to 2 etc. But there isn't any capacitance change. I guess my old data stamp to old retention policy. How can i trigger manually ?

+ I want to delete inactive backup data for some nodes is it possible inTSM 6.3?

Regards
 
PREDATAR Control23

Hi again,

Actually, there are two records for each policy domain. Which one should I change ?

DBDOM ACTIVE STANDARD STANDARD 3 1 45 No Limit
DBDOM STANDARD STANDARD STANDARD 3 1 45 No Limit
FILEDOM ACTIVE STANDARD STANDARD 10 10 45 No Limit
FILEDOM STANDARD STANDARD STANDARD 3 3 15 No Limit

I have storage problem, it is running on over %97 threshold. I am thinking reduce the version data exist parameter for some policy domain.

What is your advice about this situation?

Regards,
 
PREDATAR Control23

After changing your standard policy set you need to validate and activate it. Expire inventory has to run before you'll see any changes in your storage pools.

See HELP VALIDATE POLICYSET and HELP ACTIVATE POLICYSET
 
PREDATAR Control23

After changing your standard policy set you need to validate and activate it. Expire inventory has to run before you'll see any changes in your storage pools.

See HELP VALIDATE POLICYSET and HELP ACTIVATE POLICYSET

Hi CoMaboy,

I'm trying this. Thank you so much for reply.

When the activate my new policyset the old data will be mark inactive and delete via TSM Server, am i right?

By the way what is standard and active? When i click a domain's management class, i see only standard.

Regards,
 
Last edited:
PREDATAR Control23

Expire inventory has to run to inactivate and delete the old data. It probably runs daily via some housekeep script but you can run it manually if you want.

The active policy set is the copy TSM is currently using. You cannot edit it directly, instead you edit the standard one. Once satisfied you then validate and activate.
 
PREDATAR Control23

Hi CoMaboy,

i changed standart policyset, then validated and activated that. there isn't any changes on storage. I'm waiting for 20 hours with patience and curiosity :confused:

Thank you so much for reply.
 
PREDATAR Control23

Hi Again,

The VALIDATE POLICYSET and ACTIVATE POLICYSET command's output below. I could not be sure everything normal :confused:


tsm: BACKUPS1>validate policyset MAILDOMAIN STANDARD
ANR1557W The space management migration destination in management class
STANDARD does not refer to a defined storage pool: SPACEMGPOOL. If this pool
does not exist when policy set STANDARD is activated, clients will fail when
using this management class to migrate space-managed files to the server.
ANR1515I Policy set STANDARD validated in domain MAILDOMAIN (ready for
activation).

tsm: BACKUPS1>activate policyset MAILDOMAIN STANDARD
ANR1557W The space management migration destination in management class
STANDARD does not refer to a defined storage pool: SPACEMGPOOL. If this pool
does not exist when policy set STANDARD is activated, clients will fail when
using this management class to migrate space-managed files to the server.


Do you wish to proceed? (Yes (Y)/No (N)) Y
ANR1557W The space management migration destination in management class
STANDARD does not refer to a defined storage pool: SPACEMGPOOL. If this pool
does not exist when policy set STANDARD is activated, clients will fail when
using this management class to migrate space-managed files to the server.
ANR1514I Policy set STANDARD activated in policy domain MAILDOMAIN.
 
PREDATAR Control23

Hello Everyone,

i found some info about this situation.

1- you have to identify backup file in backup copy group or archive copy gorup?
2- If backup file in backup copy pool you can changed retain only ver parameter and the other.
3- Then policy changed you have to validate and activate this policy set
4- Lastly you have to run expire inventory command or wait the backup schedule complete about changed policy domain.

Of course you can view the process with q pr command.

Regards,
 
PREDATAR Control23

delete backup expired data - three potential possibilities

Hallo brsrylmz,

1.) if you change the copygroup parameters (e.g. reducing the verexist= from e.g. number 5 to 4 versions) and activate the policyset, this does NOT mean, that the 5th version is deleted at once after the next expire inventory process.

You have to do another backup (and afterwards the expire inventory) of the original data in order to initiate a real expiration of the oldest 5th version. Only a new backup is triggering the application of the new policy rule(s) (kind of "rebinding").

2.) you can also delete expired versions of backup data of a node with:

in dsmc: delete backup c:\<filespec> -subdir=yes -deltype=inactive

(the node has to be allowed to delete backupdata with: update node <node> backdelete=yes)

3.) in oder to delete the complete node/client data: on the server: delete filespace <node> * - attention this can be dangerous, if wrong node / client is used!!!

the delete filespace and the delete backup commands will at once delete also the pointer in the TSM database (this is kind of implicit expire inventory)

hope that this helps.

rgds Michael.Malitz @tsmpoweradmin.com
 
PREDATAR Control23

Hello,

1.) if you change the copygroup parameters (e.g. reducing the verexist= from e.g. number 5 to 4 versions) and activate the policyset, this does NOT mean, that the 5th version is deleted at once after the next expire inventory process.

You have to do another backup (and afterwards the expire inventory) of the original data in order to initiate a real expiration of the oldest 5th version. Only a new backup is triggering the application of the new policy rule(s) (kind of "rebinding").

Actually the backup process and schedules running everyday. So

2.) you can also delete expired versions of backup data of a node with:

in dsmc: delete backup c:\<filespec> -subdir=yes -deltype=inactive

(the node has to be allowed to delete backupdata with: update node <node> backdelete=yes)

I guess 'deltype=inactive' parameter does not work on 6.3 TSM system or the parameter running only file type backup. By the way just for learn; update node <node> backdelete=yes command run before delete backup command?

3.) in oder to delete the complete node/client data: on the server: delete filespace <node> * - attention this can be dangerous, if wrong node / client is used!!!

the delete filespace and the delete backup commands will at once delete also the pointer in the TSM database (this is kind of implicit expire inventory)

hope that this helps.

Actually i tried this. I deleted 2.1TB data via delete filespace <node> * command does not change anything on storage.


Backups and shecules working on everyday successfully. I run expire invemtoey command after some file deleted. I don't understand this system.
Thank you for interest.
Regards
 
PREDATAR Control23

Hallo brsrylmz,

ad 1: if every day all schedules are running well, than the old data should expire

ad 2: delete backup command is a BA client command ( see dsmc: ) and yes, update node ....... is to be executed first on the TSM server.

ad 3: your delete filespace command is OK.

How, with what command(s) do you check your storage pool occupancy?

rgds Michael
 
Top