Schedule misses, client using wrong node name & drastic backup slowdown

[wirb]

Hi all,



Running TSM 5.2.4.5 on Win2k, all clients are 5.2.4



got a couple of issues that have me stumped.



I have a node that had the client re-installed after the node name changed. It still thinks it's the old node. It's backing up the data (in addition to the new node with the old name). But I can't get it to use the new node name. The client's managed by the CAD. DSMSCHED.LOG shows the CAD polling for the correct schedule time but using the wrong node name. The node is defined in TSM with the new name, and associated with the schedule using the new name (it's the 2nd node associated with this schedule). Here's what I've done:



- updated the nodename and password on client via dsmcutil

- done the same again, updating password on the server

- There was no administrator defined for that node; all our other nodes have administrators (their node names, listed in the "administrators" section of TSM management GUI). So I defined an administrator for it, using the other node administrators as a guide.

- the node definition has the correct TCP/IP name and address.

- I even forced the node name setting in DSM.OPT



I'm wondering whether deleting and re-registering the node will help (I did not do the original node registration). In the meantime, I could use some ideas about this.



Also, at the beginning of this week, one of our nodes that normally takes about 4 hours to back up suddenly started taking 2 days. No changes have been made; the amount of data has not changed much, it's clean of virii etc, the virus scanner is not curently scanning, previous backups have been running flawlessly. Looking at CPU usage dsmsvc is taking 96 MB of memory, which is normal, but the CPU's pegged at 100%. Any ideas other than killing the backup and bouncing the CAD??



thanks everyone!

 

[kweigel]

Hi,

check your dsm.opt on the client, there should be only one nodename-statement with the new name. Logon on the client with dsmc and check the Server with q se or the actlog, which nodename has connected. When you restart the CAD-service you should also see an entry in the actlog with the nodename.

For your long running client check the ip-setting for full-duplex and speed on client and switch, auto-negotiation is in most cases the reason for slow traffic.

karl

 

[wirb]

Kwiegel, the duplex/speed settings on the NIC seem to have been the issue. While I had seen that crop up in my search of the forum, I was doubtful since the backups have been running so well previously, and we haven't touched any settings on the server, nor had the amount of data changed from its normal range. Oh well, yet another reminder never to discount even the most unlikely possibility when it comes to troubleshooting.



As for the node name problem, we've decided here that it actually isn't a problem at all. The data on the old node really is logically a subset of the data on the new one; we just sort of split the functions previously performed on one server between two. In our case, if we had to do a DR restore, those data would all be restored to a single node anyway. As far as TSM is concerned, that other node is just another session from the same node, it's working, so we're leaving it as is.



The dsm.opt file did have only the one nodename statement BTW. But many thanks for the tips.