What is the nature of the failed backup? That is, how do you know it failed? Also, just to be clear, is the status "missed" or "failed"? Sometimes the word "failed" is used synonomously with "missed" when, from TSM's perspective, they are not the same thing... just want to be clear.
Without more detail, it is difficult to say for sure what the problem might be. Things that I can think of off the top of my head include: - The scheduler is not running on the client machines. - There is a network/firewall problem preventing the client or server from contacting each other. - The scheduler is running with SCHEDMODE POLLING (which is also the default SCHEDMODE setting), and QUERYSCHEDPERIOD is a relatively large interval. Things to check: - Confirm whether you are dealing with a missed or failed schedule. - Check the TSM server activity log around the time that the client schedule started (or should have started). For a failed schedule, look for any messages related to that client from the time the event started to see if there are any messages that might hint at the problem. For a missed schedule, see if the server was trying to contact the client. Note: if you use SCHEDMODE POLLING, the server will not try to contact the client; in which case, look further back in the activity log for any messages related to the client that might hint at the trouble, or at least the last time the client successfully contacted the server. - Make sure the node is not locked. - If the schedules were missed, make sure the server is configured to support enough concurrent sessions to allow all node backups to start before the schedule window expires. - Make sure the server is not disabled for client sessions. - Examine the failed node's dsmsched.log and dsmerror.log files for information as to why the schedule might have failed (or missed). If the dsmsched.log indicates that the operation started but did not end, then maybe the scheduler is hung. - Make sure the scheduler is running on the client. If you are using the CAD to manage the scheduler, make sure the CAD is running; check dsmwebcl.log to see if the CAD is having any difficulties. - Make sure the client can contact the server. For example, maybe the client node's password has not yet been encrypted on the client, which would cause a schedule to not run. Run the command line or GUI client just to ensure basic connectivity. - See if there are any network (including firewall) problems that need to be resolved. From the server machine, can you ping the client? From the client machine, can you ping the server (more basic connectivity checks)? Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] IBM Tivoli Storage Manager support web page: http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" <[email protected]> wrote on 07/26/2006 02:23:54 AM: > Hi to all, > > Have a quick question - what's the best way to rerun failed backups? > I've tried through the ISCADMIN>TSM>POLICY DOMAINS route and using the > schedule wizard but al that happens is the jobs sit there in pending > state all day - what am I doing wrong?? Using TSM 5.3.3 on a W2K3 > platform > > TIA > > Gary > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be > copied, disclosed to, retained or used by, any other party. If you > are not an intended recipient then please promptly delete this e- > mail and any attachment and all copies and inform the sender. Thank you.
