We're trying to backup two nodes on a Linux client, one is the system and the other DB2. I have two nodes in TSM: node1 and node1_db2. My question is how to configure the dsm.sys and the scheduler on the client to accomplish this. I currently have a dsm.opt and a dsm.sys for each node. The node1 config files are located in /opt/tivoli/tsm/client/ba/bin. The node1_db2 config files are in /opt/tivoli/tsm/client/api/bin64. I can backup the node1 server from the TSM scheduler. I can also backup node1_db2 from shell scripts. I don't know how to combine the two for the scheduler though. We have very few Linux clients so don't have a lot of experience on them.
-
-
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.
Backing Up Two Nodes on a Linux Client
- Thread starter jgraul
- Start date
Hi,
having two dsm.sys files is not a good idea - create just one with two stanzas in it (in one location) and use symbolic link pointing to this file in the other location. Use dsm.opt files to point to the corresponding stanzas in the dsm.sys (using appropriate "SERVERNAME XYZ" selector)
Example of dsm.sys:
What you need next are two scheduler "services" - use environmental variables to point to corresponding dsm.opt files when starting them. This is how it can be done:
Example: /opt/tivoli/tsm/client/ba/bin/dsmsched.rc:
There is another way (as always in TSM) - you can get away with a single scheduler - in case your schedules do not overlap you can backup the file-level node using "action=incremental" schedule and the DB2 node using "action=command" schedule (run by file-level node scheduler) running the script for DB2 backup ....
Hope it helps
Harry
having two dsm.sys files is not a good idea - create just one with two stanzas in it (in one location) and use symbolic link pointing to this file in the other location. Use dsm.opt files to point to the corresponding stanzas in the dsm.sys (using appropriate "SERVERNAME XYZ" selector)
Example of dsm.sys:
Code:
servername client2
commmethod tcpip
tcpport 1500
tcpserveraddress x.x.x.x
passwordaccess generate
nodename client2
servername demotsm5
commmethod tcpip
tcpport 1500
tcpserveraddress x.x.x.x
passwordaccess generate
nodename linux2What you need next are two scheduler "services" - use environmental variables to point to corresponding dsm.opt files when starting them. This is how it can be done:
Example: /opt/tivoli/tsm/client/ba/bin/dsmsched.rc:
Code:
#!/bin/bash
DSM_DIR=/opt/tivoli/tsm/client/ba/bin
DSM_CONFIG=/opt/tivoli/tsm/client/ba/bin/dsm.opt
DSM_LOG=/opt/tivoli/tsm/client/ba/bin
LC_CTYPE=en_US
LANG=en_US
LC_ALL=en_US
export DSM_DIR DSM_CONFIG DSM_LOG
export LC_CTYPE LANG LC_ALL
/opt/tivoli/tsm/client/ba/bin/dsmc sched > /dev/null 2>&1There is another way (as always in TSM) - you can get away with a single scheduler - in case your schedules do not overlap you can backup the file-level node using "action=incremental" schedule and the DB2 node using "action=command" schedule (run by file-level node scheduler) running the script for DB2 backup ....
Hope it helps
Harry
Normally I would put the DSM environment variables in /etc/profile. Should I remove the DSM_CONFIG from there and add them to the appropriate resource files for each services? That way they are set for each process as the process is started? I will have to check out setting up a service for dsmc sched. Right now I just have it starting in /etc/inittab.
Hi,
there is no problem with putting that "dsmsched.rc" file(s) into /etc/inittab
Having the variables set in the profile makes no harm - the "dsmsched.rc" sets the variables for itself only
Harry
there is no problem with putting that "dsmsched.rc" file(s) into /etc/inittab
Code:
tsm::respawn:/opt/tivoli/tsm/client/ba/bin/dsmsched.rcHaving the variables set in the profile makes no harm - the "dsmsched.rc" sets the variables for itself only
Harry
Hi,
TSM client configuration files are:
main configuration file - dsm.sys (this name is set and cannot be changed)
options file - this is (by default) dsm.opt - but it can have any name (even does not need to end with *.opt) - TSM uses DSM_CONFIG variable to find it (defaults to /opt/tivoli/tsm/client/ba/bin/dsm.opt when this is not set).
Makes sense now?
Harry
TSM client configuration files are:
main configuration file - dsm.sys (this name is set and cannot be changed)
options file - this is (by default) dsm.opt - but it can have any name (even does not need to end with *.opt) - TSM uses DSM_CONFIG variable to find it (defaults to /opt/tivoli/tsm/client/ba/bin/dsm.opt when this is not set).
Makes sense now?
Harry
