In order for the TSM client to perform an automatic scheduled backup, the TSM Scheduler must be running on the client machine during the allotted scheduled window. As all scheduled windows at OUCS occur overnight, between 18:00 and 06:00, this means that the client machine must be running the TSM scheduler and the machine left switched on overnight on the night(s) of the schedule window.
During the installation of the TSM software you may have been given the option to enable the scheduler. If you didn't answer yes to this you, or you have subsequently disabled the scheduler, you can enable the scheduler by running
/opt/tivoli/tsm/client/ba/bin/HFSscheduler onThis will both start the scheduler and configure the system to start it at boot time.
/opt/tivoli/tsm/client/ba/bin/HFSscheduler offThis will both stop the scheduler and configure the system not to start it at boot time.
- dsmsched.log - the log of the all scheduled backups. This file lists the details of each file processed in the most recent scheduled backups, the summary results of the most recent scheduled backups and the time of the next scheduled backup.
- dsmerror.log - lists any errors encountered in any manual or scheduled backup.
03-12-2009 08:19:13 --- SCHEDULEREC QUERY BEGIN 03-12-2009 08:19:13 --- SCHEDULEREC QUERY END 03-12-2009 08:19:13 Next operation scheduled: 03-12-2009 08:19:13 ------------------------------------------------------------ 03-12-2009 08:19:13 Schedule Name: WEEKDAILY_OUCS 03-12-2009 08:19:13 Action: Incremental 03-12-2009 08:19:13 Objects: 03-12-2009 08:19:13 Options: 03-12-2009 08:19:13 Server Window Start: 00:00:00 on 04-12-2009 03-12-2009 08:19:13 ------------------------------------------------------------ 03-12-2009 08:19:13 Schedule will be refreshed in 12 hours.
If the next schedule window is more than 12 hours away the last line will say "Schedule will be refreshed in 12 hours" as above. If sooner it will say something like "Command will be executed in 5 hours and 27 minutes".
dsmc query schedule
Output from the Scheduler process is appended to the end of the
dsmsched.log file and any errors are written to the
dsmerror.log file. It is important to regularly
examine the schedule log for details of the latest scheduled backups. The
TSM Scheduler will have written summary information of the last scheduled
backup similar to below
02-12-2009 18:36:28 Normal File--> 539 /var/log/exim4/mainlog.9.gz [Sent] 02-12-2009 18:36:28 Normal File--> 9 /var/spool/anacron/cron.daily [Sent] 02-12-2009 18:36:28 ANS1802E Incremental backup of '/' finished with 3 failure 02-12-2009 18:36:28 --- SCHEDULEREC STATUS BEGIN 02-12-2009 18:36:28 Total number of objects inspected: 184,395 02-12-2009 18:36:28 Total number of objects backed up: 995 02-12-2009 18:36:28 Total number of objects updated: 26 02-12-2009 18:36:28 Total number of objects rebound: 0 02-12-2009 18:36:28 Total number of objects deleted: 0 02-12-2009 18:36:28 Total number of objects expired: 782 02-12-2009 18:36:28 Total number of objects failed: 3 02-12-2009 18:36:28 Total number of bytes transferred: 498.21 MB 02-12-2009 18:36:28 Data transfer time: 39.90 sec 02-12-2009 18:36:28 Network data transfer rate: 12,786.00 KB/sec 02-12-2009 18:36:28 Aggregate data transfer rate: 3,470.37 KB/sec 02-12-2009 18:36:28 Objects compressed by: 0% 02-12-2009 18:36:28 Elapsed processing time: 00:02:27 02-12-2009 18:36:28 --- SCHEDULEREC STATUS END 02-12-2009 18:36:28 --- SCHEDULEREC OBJECT END WEEKLY_18_30 02-12-2009 18:30:00 02-12-2009 18:36:28 Scheduled event 'WEEKLY_18_30' completed successfully. 02-12-2009 18:36:28 Sending results for scheduled event 'WEEKLY_18_30'. 02-12-2009 18:36:28 Results sent to server for scheduled event 'WEEKLY_18_30'. 02-12-2009 18:36:28 ANS1483I Schedule log pruning started. 02-12-2009 18:36:28 ANS1484I Schedule log pruning finished successfully. 02-12-2009 18:36:28 TSM Backup-Archive Client Version 6, Release 1, Level 0.2 02-12-2009 18:36:28 Querying server for next scheduled event.
Next, it is important to determine if any files have failed to backup. If the 'Total number of objects failed' is greater than zero then scroll up the file for the next occurrence of the word 'fail' to determine which file(s) this affects. The most common reason for a file failing to be backed up is that it is held open (locked) by another program. In this case, the choice is either to close the program before the backup, or exclude the file from the backup process. Examples of how to do this can be found in our page on how to exclude files and folders from backup.
Note that the schedule log file does not grow endlessly, but is pruned of
entries older than the setting of the
SchedlogRetention option in the
dsm.sys file. By default this is set to 30 days. See
the entry in the TSM client online Help for possible values for this
The first of these can be determined by running a manual backup via the TSM Backup program. If this works then there is probably no configuration problem. If you get an error running the TSM Backup program, then please review the steps involved in installing and configuring the TSM Client software.
Check that the 'dsmc sched' process is running. If it has stopped, please examine the
dsmerror.log files for an
explanation. Try repeating starting the TSM Scheduler as detailed in the Starting the TSM Scheduler section.
If the above fails, bundle the log and configuration files listed below and send these as an attachment to email@example.com with a subject line containing 'TSM Schedule'.
/var/log/dsmsched.log /var/log/dsmerror.log /opt/tivoli/tsm/client/ba/bin/dsm.sys /opt/tivoli/tsm/client/ba/bin/dsm.opt