Alternate dsm.opt files

TeEsEm

ADSM.ORG Member
Joined
Oct 18, 2004
Messages
75
Reaction score
0
Points
0
Website
http
Drew, my apologies for the previously vague subject.



Client version 5.2.3 (I can upgrade to 5.3 if necessary)

Client OS: Win 2003 Ent.

Server Ver: 5.2.1.2





I need to be able to 1. point to an alternate dsm.opt file for different backups, or 2. have only certain files backup at certain times.



For instance: I want an a standard incr to run nightly EXCLUDING pst files. I want ONLY PST files to be backed up on Sat.



I was told to use this command dsmc incr -su=yes -optfile=dsm2.opt but the tsm client does not like the -optfile command. I cannot seem to find an answer in the redbook.



Any help would be appreciated.



Thanks
 
you said "the tsm client does not like the -optfile command" ????????



it's not possible.



it got to work, the "-optfile=xxx" is made for the command line.



here we have a node wich use 4 differents "xxx.opt" file.



can you show us the error message..
 
Hi TeEsEm,



Did you try using the full path to the alternate dsm.opt file? Also, it may help to quote your path too.



It looks like your running it directly from the command line. If you are using a scheduler, you can use the dsmcutil to specify a scheduler with the proper opt file (using the -optfile aparameter).



Normally on Windows clients, we create a shortcut on the desktop too pointing to the proper opt file and rename the shortcut appropriately. Here is an example of one from a desktop Win2k3 machine I use:



F:\Tivoli\TSM\baclient\dsm.exe -optfile=E:\Tivoli\TSM\baclient\dsm.opt



and it works well for us.



The commnand I use with the dsmcutil (You need to be in the proper directory to execute this unless it is in your path) is similar to (I modified it a bit to not include acutal names):



dsmcutil install SCHEDuler /NAME:"TSM-Cr-Scheduler" /clientdir:"E:\Tivoli\TSM\baclient" /optfile:"F:\TSM-Cr-config\dsm.opt" /node:NETPROCSBTSVC_BIZTALKGROUP /password:netbt_btgrp /validate:yes /autostart:yes /startnow:no /clusternode:yes /clustername:netbt /eventlogging:yes /errorlog:"F:\TSM-bt-cfg\Logs\bt-TSM-error.log" /schedlog:"F:\TSM-bt-cfg\Logs\bt-TSM-schedule.log"



Hopefully this gives you somewhere to begin.



Let me know how you make out.



Drew
 
Make sure you have double quotes where ever there is a space in the path like



-optfile="C:\Program Files\Tivoli\TSM\Baclient\dsm2.opt"



Also make sure that anytime you schedule a command through the scheduler you provide the complete path as we have seen TSM fail unless that is provided...again use double quotes if there are any spaces in the command path. I would also point out that an upgrade to at least 5.2.4 client should be done as there are known system state backup issues with Win2003 and clients below 5.2.4. I didn't get a clear enough picture but you are using an different nodename for those PST backups I hope.
 
I am still having issues with the system state and system services with the 5.2 TSM client as well on Win2k3 machines.
 
Another way you can use is to define client options sets (with particular include/exclude) and associate appropriate with weekday/weekend schedules.



And finally you can use environment variable DSM_CONFIG which specifies the opt file.



But -optfile parameter should work, we have no problems with it either.



Hope it helps
 
Should I be using a different node name? All the input i'm receiving is great, but i'm confused on exactly what i should and should not be doing. I have a client schedule set to run on that server (set from my TSM Server) to run nighly incr at 10pm. This schedule uses that standard dsm.opt file which excludes pst files. I want another schedule to run on the same node but only on sat which just backs up pst files. I'm sure there are numerous ways to do this but what is the proper way for me to set this up?



dsmc -optfile"xxx" worked. Thank you for that help. I had it setup wrong.
 
Itdrew,



"the system state and system services" problems (shadow copy errors) on the win2k3 client are resolve on the 5.3 or higher TSM client.



I was facing them and by upgading to 5.3.0.14, everthing is fine
 
TeEsEm,



my opinion is to have only one node set has normal (excluding your *.pst) wich run week's night

and



about the week-end backup for the PST, i will recommand you to create a new x.opt file and a new managment Class for your *.PST files.



set on your second opt file ==> "Include *:\...\*.PST MGNTCLASS_PST"



and lunch the backup with "dsmc i \\nodename\d$\...\*.PST -optfile="C:\Program Files\Tivoli\TSM\Baclient\dsm2.opt""



set the MGNTCLASS_PST with the a "Versions Data Deleted" parameter with one more version, because your week backup will excludes them from backup so expire the latest backup file.



so you should never have a active PST file on your TSM Database.
 
You could also use a different node name for the weekly backups in the x.opt file, and then the .pst files won't be expired during the nightly bakups.



In other words, have two different node names, one for the nightly backups and one for the weekly backups, each with there own set of incl/excl and management classes.



Does anyone have any comments on this approach?
 
This one is probably safer, because active version of files will never expire, meanwhile using management classes will mark *.pst as inactive. That can cause troubles, if backup will not run for a time. But on the other hand you can specify retonly to nolimit which will guarantee "simmilar" behavior.

Depending how often are these files deleted (and created new ones) I would consider appropriate solution.



often deleted -> 2 nodes (and possible 2 MCs, if needed different number of versions/retention periods)

rarely deleted -> 1 node with 2 MCs (easier management and restore)



I can't see any other benefits/impairs at the time..
 
So let me get this straight. I run my nightly incr excluding pst files. Once every Sat, i run this command:



dsmc i -optfile="c:\program files\tivoli\tsm\baclient\dsm2.opt



which dsm2.opt excludes all but includes *.pst . It also points to a different mgmt class. If i do this, then everything should be ok? I"m sorry i sound vague, but i'm still a bit lost with all the suggestions.



Thanks again for all the help.
 
<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>In other words, have two different node names, one for the nightly backups and one for the weekly backups, each with there own set of incl/excl and management classes.</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



I use this method to seperate the System State backups for Nodes over a WAN link. I have a two Nodes, two dsm.opt files and two schedules (each pointing a different option file - configured as different Nodes) and it work great for me.



:)
 
Yes You are good if you use two separate nodename for the two backup.

:)



if you want to use only one nodename you should not specify the "excludes all " in the dsm2.opt, 'cause with that you will expire the data you backuped in the week.





==> I think ITDREW is right and you should use two different nodename for your two backups ;)



have fun
 
Is this the case with having two different Servers as well?

We are migrating from Old_Server to New_Server, so some of the Directories/Filesystems will be moved to the new server, rest will remain on the old server.



Should I use two opt files just like that? Any complexities foreseen?



thanks in advance.

:rolleyes:
 
Yes, for 2 servers I'd prefer 2 nodes definetely, mainly because of lucidity. In this case you will also need 2 schedulers.
 
Back
Top