Growing dsmsched.log

[Jonte]

Hi

I notices on some of my nodes dsmsched.log grows fast in size. Inspecting the file it seems that it actually contains some kind of backup historie listing all backed, expired and so on files. Interessting reading but is this really correct and is dsmsched.log rotated by TSM?

 

[GregE]

Set your rentention in dsm.opt

Example

SCHEDLOGRETENTION 30 D

 

[Jonte]

Example

SCHEDLOGRETENTION 30 D

Tnx!

But is it a normal behavior that all this information is stored in this log file, consider that we have alot of activity on the node it will grow big rather fast!

 

[icewalker]

Yes it is normal for all of that information to be in the log files.

We used options in our dsm.opt file to relocate all of the logs to a separate folder and then a small VBscript on the Windows Servers rotate the log files for us (a lot like linux does with its logs) to a new filename with a datestamp on them. We then make sure the rotated log files are backed up. The script also deletes any files that are older than 40 days.

The nice thing is that you get manageable files that are easy to identify.

I have upon occasion needed to review the log files to determine what happened during a backup. We've had times where a file(s) was not backed up but others were. And because the system in question was rebuilt and restored, if it weren't for the log files, I couldn't tell the admin why the files in question were missing from the backups (admin error on their end for editing the dsm.opt file without me).

James

 

[Jonte]

Oki, i can see the benefits of having this information handy, but isnt the same information stored in Db on the server? my wish is to have acces to this log via ISC.

 

[icewalker]

No, TSM doesn't do the rotation. However, if you have set up your services to use the Client Acceptor Daemon, each time the scheduler starts, you can trim your logs. That is where the schedlogretention comes in. You can set it for 1 D or 30D. Whatever.

However, as you saw, the log file can get large. That is why we wrote the VBScrip for Windows Servers. We keep the log file sizes manageable so we can actually review them if necessary.

Just because TSM says all is fine, doesn't mean that is the case. Having these logs let's you keep tabs on each node. As a system admin, you will want to review them occasionally to verify that files are being sent. You will also want to see if there are files that are always needing a retry, etc.

 

[gyuzik]

You can also use the schedlogmax option in the dsm.opt file.

"The schedlogmax option specifies the maximum size of the schedule log, in megabytes."

example

schedlogmax 100

 

[ttrinh7975]

Jonte-

Another thing to consider, add the dsmsched.log and dsmerror.log to your dsm.opt and dsm.sys to be exclude from your backup.