Jump to content

Windows clients repeatedly "deferring" backup overriding server requests


Recommended Posts

Oddly enough -- on *this* client -- setting the countdown to zero worked. However, I can unequivocally state that it made no difference to the WinXP client of a few weeks back.

 

After "zero" started the backup, I stopped the backup and reset the client countdown to 30 seconds (it was 1 minute previously) in the script. Back to deferring.

 

All my PCs are running VirusScan 7.1 -- so it's not specifically indicative of that (necessarily) because all of them run this.

 

Screen Saver is *not* on -- in fact the user was at the computer while all this was going on and working on a Word document.

 

He never sees anything come up to defer the backup. In fact, the *client* is set to back up "as soon as possible"

 

I can't rule out "shareware" causing an adverse reaction, though -- give me some examples that you know of that *does* affect this from coming up and I can see if the user has any of it on the machine.

 

 

I'm stumped. Something *on the client* is doing the deferring. I've even tried (as before) adding the client to another machine running Retrospect. No luck. It's not the backup server acting up. It's all about the client.

Link to comment
Share on other sites

Unfortunately, the days of "Kill everything but SysTray and Explorer" are long behind us. The MSCONFIG utility should prevent anything else from loading on boot, unless you've got some shortcuts in the Startup Items folder (which I should have mentioned in my prior post). After boot, with the MSCONFIG changes mentioned previously, do you see anything non-standard running as a process? I wouldn't expect to see Norton, for example.

 

Something else to try, which may or may not have any effect but worth a shot none the less, would be to:

 

1. Run the backup while the machine is logged out

2. Run the backup while logged into a new user account

 

Report back when possible.

Link to comment
Share on other sites

Tried both (waiting at the login screen and logging into a different account.)

 

Same deal -- still deferring the backup.

 

Even after completing a backup with "zero" countdown, I can't get it to backup again if I reinitiate the countdown.

 

I have plans to reformat this computer tomorrow (Thursday) and am willing to try something else in the meantime, but I don't believe I can leave my countdown at "zero" for all my client computers. They probably wouldn't like the option taken away from them to defer the backup.

Link to comment
Share on other sites

The tail end of the file looks like this:

 

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 276

1079359000: transSubPiper: writing code = 300, tid = 7, count = 0

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 276

1079359000: transSubPiper: writing code = 300, tid = 7, count = 0

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

 

 

there are a *lot* of the last line throughout the entire retroclient.log file with varius "counts" (mostly 644).

Link to comment
Share on other sites

For what it's worth...

 

Upgrading to this new client and restarting the Win2000 machine still would not let it do a backup server backup -- it's still repeatedly deferring.

 

 

Might there be some 3rd party "popup blocker" software product that interferes with the Retrospect "countdown" screen? If so, what should I be looking for?

Link to comment
Share on other sites

  • 3 weeks later...

I'm having the same troubles here. One MS Windows 2000 client started deferring automatically. I updated to the nearly latest and greatest (meaning the latest and greatest for Retrospect 5.1), all to no avail.

 

His system: MS Windows 2000 version 5.00.2195 sp4. Deferring started when using client v6.5.131 and continued for client v6.5.136. The only new software he recalls having put on the computer of late was the Google toolbar inside of MSIE. Of course, it would be bizarre if this were blocking the dialog box from Retrospect (which isn't even a real popup window) when MSIE isn't running.

 

My system: Mac OS X 10.3.3 version 5.1.177 using the 4.3.103 drivers. The problem started when I was using 5.1.175 with the 4.2.105 drivers.

 

It would be nice if someone would find the solution to this problem.

 

-- Bill

Link to comment
Share on other sites

Hi

 

Does your client respond to standard backup scripts?

Does creating a separate backup server script for this client make any difference? Have you tried uninstalling the current client and downgrading to the 6.0 Windows client?

 

Thanks

Nate

Link to comment
Share on other sites

Does your client respont to standard backup scripts?

Yes. I made a plain old backup script, fired it up, and it started looking through the client hard drive.

 

Does creating a separate backup server script for this client make any difference?

No. The backup server scripts defer regardless of which script tells it to back up anything from the client machine.

 

Have you tried uninstalling the current client and downgrading to the 6.0 Windows client?

No. I'm not sure I'm willing to try, because of lack of time and inclination. The machine in question was working just fine until these autodeferrals started up. Since I run the backups as a sideline, rather than as a true admin, I'm looking for a solution which won't involve reinstallations each time the problem occurs. From what Maser says earlier, reinstallation sometimes works, sometimes fails. Still, I'll keep it in mind if no real solution comes up soon.

 

Thanks for the questions, though.

Link to comment
Share on other sites

Here's a thought about what could cause the trouble (a shot in the dark):

 

For a couple of backups before the autodeferrals, there were some communications errors. During the last semi-successful backup, one hard drive backed up just fine, but during the backup (not the compare) of a second drive attached to the machine, there was a '519 network communication failed' error. I would guess that the person at the client computer unhooked the external drive while getting ready to leave for the day.

 

So... my guess is that some file which retrospect uses on the client machine was left in a bad state, and it is this file which is causing the autodeferrals.

 

Unfortunately, I have no clue how to track down such a mystery file, since I know little about temporary files in MS Windows. If it were a Mac problem, I'd trash preference files. Is there a similar first-try solution in the MS Windows world?

Link to comment
Share on other sites

Hi

 

An uninstall and reinstall of the client would accomplish that.

 

Can you try uninstalling/reinstalling/updating your Network adapter drivers? I would install the client after doing that. Can you try another NIC in the machine?

 

Thanks

Nate

Link to comment
Share on other sites

An uninstall and reinstall of the client would accomplish that.

 

This would be true if the file which were left in a comprimised state were in the files wiped by the uninstaller. If it's a tmp file it might not be noticed by an uninstaller. This appears to be Maser's experience. Still, this is probably the only solution until the underlying cause can be identified. Ugh.

 

Can you try uninstalling/reinstalling/updating your Network adapter drivers?

 

Not really. I'm a professor backing up others' machines over the school network. I'm not a sysadmin, not even for the department computers. Besides - all others' MS Windows machines are working just fine.

 

Can you try another NIC in the machine?

 

The client is a laptop. It has just one NIC. My machine is a plain old desktop. It has just one NIC. This is a really small time operation running on a big network.

 

Thanks again.

Link to comment
Share on other sites

  • 2 weeks later...

This is a follow-up:

 

An uninstall and reinstall of the client would accomplish that

 

Uninstalling and reinstalling the client did not fix the problem.

 

I went and searched the client machine for files modified on the day where the backups started failing, in hopes of finding a lock file or some other settings file which would cause automatic deferrals. While there were many files which were altered, I couldn't find anything which I thought might be traceable to Retrospect.

 

Has anyone found a cause for the autodeferral problem?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...