• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4795
  • Last Modified:

TSM Client retention backups for 1 year retention

Hi All,

I have a TSM client node on which the application filesystem has the requirement of keeping the application logs for one year retention for PCI complaince. This node I am already backing up with current policy retention of 3 months. What change I need to do to make the filesystem backup retention for 1 year and also whether it is suggested to have different TSM policy for this node? The node OS os RHEL 5.8 and TSM server is on AIX and version in

  • 8
  • 7
2 Solutions

it's not a problem at all having different policies for different filesystems
on a single node.

The method to implement this is the same we've already been discussing
in a different context earlier.

On the server (dsmadmc):

- Copy the existing management class of the domain where the node belongs to:

COPY MGMT domainname policysetname oldclass newclass

- Change the policy of the copygroup under the new class:

UPD COPYGROUP domainname policysetname newclass STANDARD T=B RETEXTRA=360 RETONLY=360

- Activate:

ACTIVATE POLICYSET domainname policysetname

On the client node:

- Update dsm.sys

If you have an existing detailed DOMAIN definition remove the filesystem in question from it,
or if you just have "DOMAIN ALL-LOCAL" change this to

DOMAIN ALL-LOCAL -/mount/point/of/fs

Note the minus ( - ) sign in front!

In either case add to dsm.sys:

INCLUDE /mount/point/of/fs/.../* newclass

Restart the client scheduler and that's it.

There are no particular considerations regarding restoration.
TSM will find the files irrespective of the management class used.

Note: All UPPERCASE words must be specified as written,
words in italic case must be replaced with your individual values.

virgo0880Author Commented:
whether it will be a backup or archive. As my requirement is to keep the files retended for 1 year. Also, whats the difference between backup and archive. I googled it but some of the terms are confusing.

If I store this as archive, then in case if I need to restore some of the batch files, what will be the process for the same.

It's backup. See T=B in the copygroup definition. Also, the default for central schedules is "Incremental" which is the term for the TSM standard "backup" method.

Archiving is a different process, involving distinct copygroups and commands.

Commands are "archive" for archival and "retrieve" for restoration.

There is just one policy setting for archiving, which is the overall retention period. There is no versioning.
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

virgo0880Author Commented:
how to find that the node's file belongs to which default management class. When I do q mgmt from TSM client node, it shows me this :

tsm> q mgmt
Domain Name               : MIS_UNIX
Activated Policy Set Name : MIS_UNIX
Activation date/time      : 07/11/2009 11:16:28
Default Mgmt Class Name   : MIS_UNIX
Grace Period Backup Retn. : 30 day(s)
Grace Period Archive Retn.: 30 day(s)

whether it means the files of that node belongs to "MIS_UNIX" management class. If that is the case , then I need to execute following commands on TSM server to create a new one year management class.... right ?




All correct! Wonderful!
virgo0880Author Commented:
Thanks :-) !!!!
virgo0880Author Commented:
Is there a way to verify whether the filesystem is backed up using the new management class. Is there any command for the same?

Under "dsmc" on the client issue

Q BACKUP /mount/point/of/fs/* -SUBDIR=YES

The  column in the middle indicates the management class.

To halt the display after every page of output add "-SCROLLP=YES"

(The commands work also in lowercase, I use uppercase just for clarification)
virgo0880Author Commented:
As per your suggestion in comment ID 37783996, I configured dsm.sys and management class, but the backup for /apps/ was skipped and did not happened. Also, I noticed that it did the rebinding of the OS filesystems to new management class which I created. Following lines were added to dsm.sys and the scheduler was restarted. Can you tell me what could have cause the /apps/ filesystem to be skipped ?

include /apps/.../* ONE_YEAR_LOGS
Yes, I can tell you. It was my mistake, and I still can't imagine why I've been writing such a nonsense.

The filesystem in question must of course be in the domain, implicitly or explicitly.

So remove "-/apps" from the DOMAIN, so that the statement reads:


The second line is OK.

As for rebinding:

When checking the backup logs carefully you'll notice that TSM has rebound only directories
to the new management class, not files.
That's normal and desired behaviour: TSM always uses the class with the longest overall retention for binding directories. Dont' worry, this will never do any harm.
On the other hand, the fact that TSM took your new class is an indication that this class has been set up correctly and is useable.

Sorry again for the inconvenience. I'm getting old, I keep telling you ...

virgo0880Author Commented:
No problem. That's OK.

But in my case in the logs it is showing that it has rebound some of the files also to the new management class. I dont want my OS filesystems to rebound to this new MC, I just want my /apps/ to go there. So, how can I rebind to their old default MC ?

Also, I will modify the line as per your suggestion and trigger the backup again to see if that works.

I never saw files getting bound to a management class other than DEFAULT when TSM hadn't been explicitly directed to do so.

So if you're really sure you should immediately open a support request with IBM/Tivoli, because this must be a bug!
virgo0880Author Commented:
Ok, I verified and found that it has rebound directories to new MC, but the files in that are bound to default MC. I was not knowing about this behaviour of TSM related to MC, thanks for pointing it out. I was looking on google for the same, but didnt found any article for that. Can you provide me the link of something, so that I can read that in more details.

Also, I triggered a backup now and this time /apps/ backup was successful and it belongs to new one year MC.

Is there any command to verify the retention details of files, wherein I can see the retention details of the particular, for e.g. i did "q ba" for one particular file and it is showing :
tsm> q ba /apps/vvpspa/tomcat/logs/vvps.log.2012-03-14.gz
           Size        Backup Date                Mgmt Class           A/I File
           ----        -----------                ----------           --- ----
    16,025,278  B  03/20/2012 17:12:48        ONE_YEAR_LOGS        A  /apps/tomcat/logs/log.2011-03-14.gz

Open in new window

Is there any switch in this command to see the expiry date of the file?

A bit of info is here:

You can also start the commandline client, issue "help" and scroll down to the entry for DIRMC and enter the given number to get the help text. In my client it's "3.4.32".

It says:
If you do not specify this option to associate a management class with
directories, the client program uses the management class in the active
policy set of your policy domain with the longest retention period.
Select a management class for individual directories that retains
directories at least as long as it retains the files associated with
I, personally, do not use DIRMC. The class with the longest retention is a good choice for binding directories.

Q BACKUP doesn't have an option to display the expiry date.
That's because TSM doesn't store such a date in its DB. Whether a file is expired or not is determined dynamically by the "Expire Inventory" process, by relating the backup date of a file to the retention period of the class this file is bound to.
It makes sense not to have such a date in the DB, because otherwise changing a class would not only imply
just rebinding the files to the new class but also adjusting the expiry date of each and every file,
which could be a lengthy process with possibly millions of files.

The only thing you can do under dsmc is

Q MGMT -detail

At " Retain Extra Versions" and "Retain Only Version" you'll see the effective retention periods.
virgo0880Author Commented:
Ok, thanks for all your help and suggestions..giving points.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 8
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now