• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

TSM 6.3 Retention Trigger

brsrylmz

Active Newcomer
#1
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
 

brsrylmz

Active Newcomer
#2
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,
 

CoMaboy

ADSM.ORG Senior Member
#3
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
 

brsrylmz

Active Newcomer
#4
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:

CoMaboy

ADSM.ORG Senior Member
#5
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.
 

brsrylmz

Active Newcomer
#6
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.
 

brsrylmz

Active Newcomer
#7
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.
 

brsrylmz

Active Newcomer
#8
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,
 

[email protected]

ADSM.ORG Senior Member
#9
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
 

brsrylmz

Active Newcomer
#10
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
 

[email protected]

ADSM.ORG Senior Member
#11
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
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 16 18.8%
  • Keep using TSM for Spectrum Protect.

    Votes: 52 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.8%
  • Other (please comement)

    Votes: 7 8.2%

Forum statistics

Threads
31,448
Messages
133,971
Members
21,548
Latest member
cburns
Top