tsm server did not start backup schedule for one client

[mick703]

Hi,

I got this very weird problem that our tsm server did not start backup schedule for a particular client. This client is in DMZ network so the communication is set to be initialized by server only. It worked before client's kernel was upgraded. But after client kernel was upgraded, this client backup schedule stopped working. The weird thing is I can not get any information from tsm activity log saying anything about this client schedule or any other error messages. It looks like this schedule for that client does not exist or tsm totally ignores it. The schedule status becomes Pending then Missed but there is nothing in the activity log. All other client nodes work properly with this backup schedule.

I checked the connectivity between this client and tsm server and it is fine. The client is listening on the right port 1501. I try updating this node, re-associating it with a test schedule and it did not work either. It seems tsm did not like this client node and refused to contact this node.

Anyone has similar issues before? Any hints? Thanks.

Mick

 

[moon-buddy]

Can the node reach the TSM Server via running "dsmc q sess" from the node?

 

[GregE]

Mick, are you running scheduler alone or having the CAD start it?

Put the node into a schedule, then go to the client, comment out the MANAGEDSERVICES line in dsm.opt (or dsm.sys if UNIX) and run the scheduler manually. "dsmc sched"

See if TSM will contact it.

 

[mick703]

Can the node reach the TSM Server via running "dsmc q sess" from the node?

Because this node is in DMZ and is not allowed initialize connection to tsm server, only tsm server can start a backup session and contact the node. I tried a couple test schedules both command and backup, only few of them were started by tsm and only worked once.

I just don't understand why there is nothing appear in the activity log when this schedule is due to start, not even an error code.

 

[mick703]

Mick, are you running scheduler alone or having the CAD start it?

Put the node into a schedule, then go to the client, comment out the MANAGEDSERVICES line in dsm.opt (or dsm.sys if UNIX) and run the scheduler manually. "dsmc sched"

See if TSM will contact it.

Actually, there is no MANAGEDSERVICES defined in dsm.sys. Here is the command I used to start the client scheduler

dsmc schedule -schedmode=prompted -sessioninitiation=serveronly

Other nodes in DMZ work properly with this command but this one.

 

[moon-buddy]

I just don't understand why there is nothing appear in the activity log when this schedule is due to start, not even an error code.

This is because it can't respond to the TSM Server to start the backup. You need to modify the ACL for the node to 'talk' with the TSM server - port 1500 by default should be allowed.

I have seen a lot of these issues and the only solution is to open up.

 

[vamsi]

try to take manually back up first
after update the sched and start the scheduler services

 

[Eldoraan]

I'm assuming this client is Linux due to the "kernel upgrade" that was done. With the new kernel, did the admin enable/disable any rules on the client firewall daemon? If it's in DMZ, and you have a physical firewall between the networks, this host may have an additional firewall process running on it blocking the 1500 series ports you need. I saw this many years ago when they first implemented the IPChains code in the kernel and the TSM client was itself blocking it's own traffic.

 

[mick703]

I have tested the communication between the tsm server and the client. It is ok and the client is running and listening on the right port 1501.

I noticed every time after I update the node on tsm server, the tsm server can start the schedule properly at the scheduled time. However, that works only for one time. Next time the schedule will not start but in pending unless I update the node again. Anyone has the same problem? It is very weird.

Mick