Link to home
Start Free TrialLog in
Avatar of virgo0880
virgo0880

asked on

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 5.5.0.0.

Thanks
virgo
ASKER CERTIFIED SOLUTION
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of virgo0880
virgo0880

ASKER

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.

virgo
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.
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 ?

COPY MGMT MIS_UNIX MIS_UNIX MIS_UNIX ONE_YEAR_LOGS

UPD COPYGROUP MIS_UNIX MIS_UNIX ONE_YEAR_LOGS STANDARD T=B RETEXTRA=365 RETONLY=365

ACTIVATE POLICYSET MIS_UNIX MIS_UNIX

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

virgo
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)
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 ?


DOMAIN ALL-LOCAL -/apps
include /apps/.../* ONE_YEAR_LOGS
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.

Thanks
virgo
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!
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?

thanks
virgo
A bit of info is here:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmaixn.doc/anragd55424.htm?path=2_1_5_2_3_3#bindmc

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
them.
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.
Ok, thanks for all your help and suggestions..giving points.

thanks
virgo