Joni -
A classic cause of this situation is that the previously scheduled backup was still running (stuck) when the next one tried to start.
In your Query Session, the key here is in the numbers: if the Bytes Sent is large, it indicates that the server has sent the client its inventory of Active files and is waiting for the client to sort and start processing it as the client then starts traversing the file system. If no data is coming back from the client, then it suggests a problem either with general (memory) resources on the client, or issues in the file system. In such a case, I would, instead of just a 'dsmc i', do a dsmc i on a small file system, to start isolating the problem. If that works, escalate to larger file systems - and suspect the one that's first in the Domain list. You indicate no errors in the dsmerror.log. See if anything in the Solaris /var/log/messages. Also exercise other client functions such as 'dsmc q fi' and 'dsmc query backup ...' and 'dsmc archive SomeFile' to further isolate the problem.
Richard Sims
On Mar 14, 2005, at 1:23 PM, Joni Moyer wrote:
Hello All!
I am having issues with a solaris server: Node Name: FJSU000 Platform: SUN SOLARIS Client OS Level: 5.9 Client Version: Version 5, Release 2, Level 2.0 Policy Domain Name: SOLARIS Last Access Date/Time: 03/14/05 12:50:13
that is trying to backup to my TSM 5.2.2.5 server on AIX 5.2. I do not see any errors within the activity logs other than that it has missed it's scheduled startup window. On the client side, there are no error messages either. We have recycled the scheduler and then tried a dsmc i incremental backup from the client command line, but it just sits there. I query sessions on the TSM server and it has a status of idlew which means it's waiting for the client to communicate more info. to the TSM server.
Any suggestions on what I can check to see why the server isn't backup up? Thank you in advance!
