Manage multiple schedule requirements on one system
In certain situations it is preferable to have more than one scheduled activity for each client system.
About this task
Normally, you can do this by associating a node with more than one schedule definition. This is the standard method of running multiple schedules on one system.
You must ensure that the schedule windows for each schedule do not overlap. A single client scheduler process is not capable of executing multiple scheduled actions simultaneously, so if there is overlap, the second schedule to start is missed if the first schedule does not complete before the end of the startup window of the second schedule.
Suppose that most of the file systems on your client system must be backed up daily, and that one file system containing critical data must be backed up hourly. In this case, you would need to define two schedules to handle this requirement. To avoid conflict between the hourly and daily backup schedule, the starttime of each schedule needs to be varied.
Suppose that most of the drives on your client system must be backed up daily, and that one drive containing critical data must be backed up hourly. In this case, you would need to define two schedules to handle this requirement. To avoid conflict between the hourly and daily backup schedule, the starttime of each schedule needs to be varied.
In certain cases, it is necessary to run more than one scheduler process on a system. Multiple processes require a separate options file for each process and must contain the following information:
- Define a unique node name for each process
- Specify unique schedule and error logs for each process
- When running in prompted mode, you must use the tcpclientport option to specify a unique port for each process.
The advantages of using multiple schedule processes:
- You can run more than one scheduled backup at the same time.
- You can specify different backup criteria for each schedule started, with the client option file or IBM Spectrum Protect server override options.
The disadvantages of using multiple schedule processes:
- A unique file space for each node name on the IBM Spectrum Protect server is created.
- When restoring the data, you must use the same node name associated with the backup.
Multiple schedule processes can run on UNIX and Linux® platforms with either the client acceptor daemon-managed method, or the traditional method of running the scheduler. In either case, there are certain setup requirements:
- Each process must run using a different node name.
- You must create multiple stanzas in the dsm.sys file for each scheduler process. In each stanza, you must define a unique node name, along with unique values for the options errorlogname and schedlogname. You might also choose to define customized domain, include, and exclude statements for each stanza.
- In your dsm.sys file, set the passwordaccess option
to generate in each stanza. The password must be generated for each
node name that is running a scheduler process, by running a command
dsmc query sess.
- If running with the schedmode option set to prompt, you should set a unique tcpclientport value for each stanza.
You must start
dsmc sched command or instance with the -servername
option to reference its unique stanza name in dsm.sys. For dsmcad,
it is necessary to define the environment variable DSM_CONFIG for
each instance of dsmcad to reference its unique option file.
servername tsm1_sched1 nodename aixsvt01_sched1 tcpserv firebat tcpclientport 1507 passwordaccess generate domain /svt1 schedmode prompted schedlogname /tsm/dsmsched1.log errorlogname /tsm/dsmerror1.log managedservices schedule servername tsm1_sched2 nodename aixsvt01_sched2 tcpserv firebat tcpclientport 1508 passwordaccess generate domain /svt1 schedmode prompted schedlogname /tsm/dsmsched2.log errorlogname /tsm/dsmerror2.log managedservices schedule
Contents of /test/dsm.opt1:
Contents of /test/dsm.opt2:
Open two shell command windows:
- In shell command window 1, enter:
export DSM_CONFIG=/test/dsm.opt1 sudo dsmcad
- In shell command window 2, enter:
export DSM_CONFIG=/test/dsm.opt2 sudo dsmcad
Note: You should enter these commands into a shell script if you intend to have the dsmcad processes started directly from /etc/inittab so that the proper DSM_CONFIG variable can be set prior to launching dsmcad.
dsmcutil inst /name:"TSM Client Scheduler1" /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt1" /node:tsmcli_sched1 /password:secret /autostart:no /startnow:no dsmcutil inst CAD /name:"TSM Client Acceptor1" /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt1" /cadschedname:"TSM Client Scheduler1" /node:tsmcli_sched1 /password:secret /autostart:yes dsmcutil inst /name:"TSM Client Scheduler2" /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt2" /node:tsmcli_sched2 /password:secret /autostart:no /startnow:no dsmcutil inst CAD /name:"TSM Client Acceptor2" /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt2" /cadschedname:"TSM Client Scheduler2" /node:tsmcli_sched2 /password:secret /autostart:yes
- Option file #1 (c:\program files\tivoli\tsm\baclient\dsm.opt1)
tcps tsmserv1.example.com nodename tsmcli_sched1 passwordaccess generate schedlogname "c:\program files\tivoli\tsm\baclient\dsmsched1.log" errorlogname "c:\program files\tivoli\tsm\baclient\dsmerror1.log" schedmode prompted tcpclientport 1507 domain h: managedservices schedule
- Option file #2 (c:\program files\tivoli\tsm\baclient\dsm.opt2)
tcps tsmserv1.example.com nodename tsmcli_sched2 passwordaccess generate schedlogname "c:\program files\tivoli\tsm\baclient\dsmsched2.log" errorlogname "c:\program files\tivoli\tsm\baclient\dsmerror2.log" schedmode prompted tcpclientport 1508 domain i: managedservices schedule