jsnyder Posted January 29, 2004 Report Share Posted January 29, 2004 If anyone can solve this one for me I will personally buy you a drink of your choice. I have multiple clients that Retrospect Server 6.5.336 cannot backup. If I watch the job what I see happen is that it gets to a certain file (file varies from server to server) and it gets stuck trying to copy it. It'll keep coming up with "Retrying" and then eventually fail the job. I cannot find any reason the file is not being backed up by Retrospect. Permissions are fine, I am using open file back up, the latest client version is being used, etc. What's even more infuriating is that Retrospect seems to be very "Dumb" about what to do next and instead of just bypassing the damn file it stops the job! Now maybe there is a setting somewhere to prevent this, but I'll be damned if I know what it is. Can anyone please help me with this? Link to comment Share on other sites More sharing options...
natew Posted January 30, 2004 Report Share Posted January 30, 2004 Hi What OS is the client running? Retrospect doesn't usually choke on a particular file - it is more likely a communication problem somewhere along the line. What hardware is the backup machine running and what backup device do you have? Are there any BIOS updates available for the motherboards? How about updated network drivers? Thanks nate Link to comment Share on other sites More sharing options...
jsnyder Posted January 30, 2004 Author Report Share Posted January 30, 2004 The client OS is Windows 2000 Server SP4. If I tell Retrospect to ignore the file in question the backup will keep going (until it comes across the next file it doesn't like). I can verify the server is still up as I was connected to it via Terminal Server as the backup was running. On several of my servers having this problem I excluded the C:\ partition today (where the problem files were located) and only had it backup the D drive. The backups completed successfully. It is definitely related to the files somehow. Whether it is an access issue or Retrospect is coming across some issue once I remove the files from the backups the backups complete for the servers. Of course I can't leave it this way as I need to make sure the C:\ drive is backed up. As for the backup server it is backing up to disk, not to tape. And it has other clients that it backs up just fine with no issues, so this is not affecting all jobs on the server. Link to comment Share on other sites More sharing options...
natew Posted February 2, 2004 Report Share Posted February 2, 2004 Hi, Anything in common about the problem files? Size, type, ownership...? Are you using the open file backup module? If you copy one of the problem files to the D drive does it cause an error there too? Are both C and D on the same channel of the hard disk controller? Thanks Nate Link to comment Share on other sites More sharing options...
jsnyder Posted February 2, 2004 Author Report Share Posted February 2, 2004 THere is nothing in common between the files that I can find. I am using the open file backup module. I have not tried copying the file to the D drive. I guess I can try that, but it really seems to me that error reporting in Retrospect needs a serious overhauling. The fact as customers we have to do a dance and move stuff around, delete preferences, etc because the product isn't reporting good errors is a little concerning. Is there any type of debugger you guys can write to allow people to get detailed logs of what exactly is causing problems? Link to comment Share on other sites More sharing options...
natew Posted February 3, 2004 Report Share Posted February 3, 2004 Hi You can turn up filesystem logging in the hidden Retrospect preferences but it isn't going to tell us much yet. If the problem truly is file based it should be reproduceable on multiple drives. In most cases errors related to backing up particular files turn out to be coincidental, with the real problem lying elsewhere. Unfortunately Retrospect and Windows are pretty complex and debuggers are not that accurate. We ask customers to help with troubleshooting as the problems can often be corrected before having to escalate the issue to devellopers and engineers. In most cases it works out to be much faster this way. One question: Is this machine the same one that "hangs when closing" in your other post? Thanks Nate Thanks Nate Link to comment Share on other sites More sharing options...
jsnyder Posted February 3, 2004 Author Report Share Posted February 3, 2004 All my backup servers ( of which I have several) experience the "Closing..." problem. Some servers more often than others, but they all experience it to some degree. So to answer your question, yes, the jobs that are getting network communication failed are on servers where I see the random "Closing..." problem. But like I said, all my Retrospect servers have the "Closing..." problem so that isn't a coincidence. As for determining the file issue, I can try copying the bad file to another partition and see what happens. My guess is it will work just fine. I don't think it is the file that is the problem, but something happening to the file during backups. But I will see what happens if I copy the file to another partition. Question: in hopes of helping to troubleshoot this, if a file was corrupt somehow (file system issue, CHKDSK needed, etc) how would Retrospect handle the file? Would it by-pass it or fail the job? QUestion 2, when it hits these files that is hangs on it comes up with a status of "Retrying...". What situations are coding into your product that would product the "Retrying..." status of the job? Link to comment Share on other sites More sharing options...
natew Posted February 6, 2004 Report Share Posted February 6, 2004 Hi Normally a bad file will give a "can't read" or "data offset" error and the backup will move right along. I can't say that I have seen a file actually cause network communication to fail. There are some thresholds built in to Retrospect that determine when a retry happens and when the communication is finally dropped with a 519 error. My guess is that clients that go into an endless retry manage to transmit a bare minimum of data on a regular basis - just long enough to keep the connection open although no meaningful data is making its way through. On Retrospect for Mac we had to implement an adjustable client cutoff threshold to resolve this issue. I suspect that if the problem were caused by a defect in Retrospect, Dantz would have tried to resolve it rather than put time and money into what some consider a workaround. What I mean to say is that there is probably more to the Retry issue than just Retrospect. In regard to the 519 error, there has been at least one case where the backup of a certian file file triggered an immediate virus scan on the client machine. At that point client communication was dropped. Is that a possibility in your case? Thanks, Nate Link to comment Share on other sites More sharing options...
jsnyder Posted February 9, 2004 Author Report Share Posted February 9, 2004 Hey Nate, Actually, one thing I came across was that one a couple of machines that experienced this problem running a CHKDSK fixed the problem. Now this has not been 100% effective in fixing it on all clients having the problem, however, this may be a step in the right direction. Any thoughts? I have tried copying the file and a regular file copy works. IN fact, since I can't get backups to work I have had to temporarily rely on robocopy to make sure I have backups of these servers. Robocopy is not running into problems, so I don't see why Retrospect would. Running out of ideas here. Anything else you can think of? Link to comment Share on other sites More sharing options...
natew Posted February 10, 2004 Report Share Posted February 10, 2004 Hi This is interesting. Especially the part about Chkdsk. Retrospect takes advantage of some Microsoft APIs that allow faster reads and writes to disk. It may be that Windows Explorer and Robocopy are not using those and as a result are less sensitive to the error. In some rare cases (usually japanese file names) a file can be damaged/unreadable/funky in a way that a volume scan will quit. When this happens the client soemtimes can't recover so the connection is dropped. That may be similar to what is happening in your case. I find that disk utils don't usually pick up the errors, however moving the file to another disk and then back again can often help. This will recreate filesystem entries for that file/folder and may fix any damaged filesyste info. Nate Link to comment Share on other sites More sharing options...
jsnyder Posted February 17, 2004 Author Report Share Posted February 17, 2004 AH, good point. Let me try some playing around with the file system and see if I can correct these issues by doing that. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.