Retrospect Stopping Prompt on Failed Network Drive (this might be a feature request)

[curioffl]

We are using Retrospect to do some "off box" backups (to a machine that is on our network and in our Windows Domain, but physically different from the box running Retrospect itself). To accomplish this we have been using the "Advanced" button for the Backup Sets and entering \\themachine\share and appropriate log in information.

 

Lately we have had a couple of intermittent problems with the share computer talking to the domain controller and when this occurs Retrospect fails because the DOMAIN\Account that it uses to access \\themachine\share is failing (which is sensible). The bigger problem is that Retrospect does not error gracefully when this happens.

 

When Retrospect's DOMAIN\Account is rejected accessing \\themachine\share, Retrospect sends up a prompt for a new password, and holds the execution unit in use until it gets one. In our case the next and then the next and then the next backup runs until all of the execution units are in use (all just waiting for a human to enter a working username and password) and once the execution units are filled it just queues jobs forever. Long after the condition between the share machine and the domain controller is gone, Retrospect is still sitting waiting for good log in information... having never sent any error notification mail.

 

The problem as I see it is that Retrospect does not send any mail regarding this condition (and/or doesn't particularly see it as an 'error' as such). The way that we discovered the problem is by manually checking the backup machine (for something unrelated), noticing a stack of log in prompts, and hundreds of waiting backup jobs, putting a hole in our available backups (ooops).

 

My feature request (or 'how do I set it up this way?') would be that if Retrospect fails to log into an "Advanced" place for disk-based storage, it would consider that an "error" and fail, send "My login credentials failed" mail and cancel that backup run, as it might with other types of communication errors.

 

I realize, of course, that this is an obscure set of circumstances (and one that we hope to solve between the share machine and the domain controller), but there may be users out there who are depending on their backups to run that are just stacking queued jobs in the same way and won't know it till they need a restoration. A 'password denied' is an 'error' and Retrospect should treat it as such, and not assume that a human is devoted to watching the Retrospect box (which, in our experience, is too reliable to warrant that). Ideally there would be no way for Retrospect to stall all of its scheduled runs without sending out any notifications.

 

Thanks.

[yatcher]

We have the same problem.

 

It would be great if there was a media timeout for such a senario as I'm sure we're not the only ones with the problem.

 

With no error generated it can be a serious problem putting a freeze on all backups until you put in some user details again.