Jump to content

519 error backing up W2K Server


Tom_Roth

Recommended Posts

We are running Retrospect for Windows version 5.6 on a Windows 2000 Server. We use it to backup the PCs & Macs in the office, the Win2K Server it's residing on, a Win NT 4.0 Server, and another Windows 2000 Server we call "Biomed_File". The two Win2K Servers are fairly new and we've just been gradually phasing them into service over the last few weeks. Retrospect has been working fine until recently when we started populating the "Biomed_File" server volumes with loads of files. Now I'm getting a 519 error when trying to back up that server. Both Win2K Servers are updated to SP3. Everything else is backing up fine including the other servers. I can browse the "Biomed_File" volumes from within Retrospect just fine too. Anyone have any ideas on what the problem might be?

Link to comment
Share on other sites

Try creating a subvolume of only this directory and try the backup - does the error 519 occur?

 

What about subvolumes of other directories?

 

 

 

If so, try a crossover cable for a direct connection between the server and the client and repeat the backup of the subvolume and/or the entire machine - do you still see the errors?

 

 

 

- Update/reinstall the NIC drivers

 

- Reinstall the TCP/IP protocols

 

- Quit/disable any third-party applications

 

 

Link to comment
Share on other sites

We have disabled the Norton Anti-Virus on both servers, the one Retrospect is on (called Apps) and the one we're trying to backup (called File). I installed updated NIC driver on Apps and File's NIC driver was up to date already. Both servers are connected via Gigabit Ethernet (copper) to a Cisco switch, literally right next to it.

 

 

 

Yesterday afternoon I performed an immediate backup on 4 of the 16 volumes on the server File and they worked beautifully. Very fast backup speeds. Then the regularly scheduled backup started at 6:00 pm last night failed but not completely. It did resolve all 16 volumes from the container and it did backup the server's "C" drive and the first volume (which has virtually nothing on it) but as soon as it tried the next volume which has about 3GB on it failed.

 

 

 

So this morning I started another immediate backup and watched it and found that its failing during the preliminary scanning of the second volume. Same point it did last night. It did not try scanning the next volume though. Once it failed scanning that second volume, it did not go on to try the next volume and so on. It just stopped at that point. Is that right?! When it fails scanning it seems to fail as soon as it gets to a volume that has a lot on it.

 

 

 

Bypassing the Retrospect Client I tried another immediate backup of server File by adding each volume from the network. This backup got past the preliminary scanning stage on all of the volumes and started to backup files. Of course when you come in that way (not through the Retrospect client) you can't backup the "C" drive of the server. Since I was just testing the scanning stage and that succeeded I stopped the backup.

 

 

 

So then I started yet another immediate backup but instead of choosing the container for server File, I selected all of the volumes individually (except the "C" drive) and this too worked, getting past the preliminary scanning. Since we hadn't backed up this server for a few days I decided to let this backup run and again, it's running very fast.

 

 

 

So, what does all this mean? Sometimes it hangs in the preliminary scanning stage and other times it works fine. When it works, it works great with some very fast backup speeds. With speeds like that, I can hardly think there's a problem with the NICs or their drivers. I have not tried a crossover cable nor have I tried installing Retrospect on another machine. The machine it's on now (Apps) is a Dell server with dual Gigabit NICs. Could the dual NICs be a problem for Retrospect? We had the second one off for awhile but that didn't seem to help. Could the Gigabit speeds be a problem for Retrospect? The server we're trying to backup (File) is a Compaq server. I understand a backup program is very demanding of it's hardware but since it works sometimes and not others it's difficult to determine what's causing it to fail during that preliminary scan. What's different about that scan when it accesses the server volume then when it's actually backing up files from that server volume?

Link to comment
Share on other sites

In reply to:

Once it failed scanning that second volume, it did not go on to try the next volume and so on. It just stopped at that point. Is that right?!


 

 

 

Yes, once a network failure error message has been generated on a client machine, Retrospect will move on past the entire client on to the next machine. An error 519 is generated by loss of network connectivity. Once the application has lost connection with the client, it does not attempt to reconnect.

 

 

 

In reply to:

Of course when you come in that way (not through the Retrospect client) you can't backup the "C" drive of the server. Since I was just testing the scanning stage and that succeeded I stopped the backup.


Nor are NTFS permissions, the registry or any system state information backed up in this method.

 

 

 

In reply to:

The machine it's on now (Apps) is a Dell server with dual Gigabit NICs. Could the dual NICs be a problem for Retrospect? We had the second one off for awhile but that didn't seem to help. Could the Gigabit speeds be a problem for Retrospect?


This shouldn't cause any conflicts.

 

 

 

In reply to:

So then I started yet another immediate backup but instead of choosing the container for server File, I selected all of the volumes individually (except the "C" drive) and this too worked, getting past the preliminary scanning.


What happens when you choose all volumes (including the C:) individually?

 

 

 

Other then the Norton, which you disabled, what else is running at the time of the backup? Are there any utility programs (Norton Utilities? McAfee Office?) running in the background? The scan process is always going to be the same - the key is to determine what is different during the various times the volume is being scanned. Also, isolate the variables - a crossover cable, a different backup computer.... See if the problem follows your troubleshooting steps. For example, does the problem go away with a crossover cable? If yes, then the problem has been isolated to an issue with the server or the client. If no, then the problem has been isolated to the network.

 

 

 

 

Link to comment
Share on other sites

 

 

 

 

Amy:

 

What happens when you choose all volumes (including the C:) individually?

 

 

 

Tom:

 

When I did it as an immediate backup last Tuesday afternoon it worked. The problem is that sometimes the backup works and sometimes it doesn't. It always resolves the Client's container seeing all 16 volumes. Last week when I did the immediate backup during the day (Tuesday) that worked fine (on the second and third try that is) but then that night it didn't work (except for the C drive and the E drive). The following night (Wednesday) it did work and then the night after that (Thursday) it didn't.

 

 

 

I just now checked the backup log for over the weekend and it ran fine on Friday and Saturday night and then failed on Sunday night. Of course when it failed I mean it got the C drive and first volume drive E (in drive letter order) and then skipped the rest (drive F and so on) with a 519 error. Since nothing changed and no one was in over the weekend what happened Sunday night?

 

 

 

Amy:

 

Other then the Norton, which you disabled, what else is running at the time of the backup? Are there any utility programs (Norton Utilities? McAfee Office?) running in the background? The scan process is always going to be the same - the key is to determine what is different during the various times the volume is being scanned.

 

 

 

Tom:

 

The server that Retrospect is on is also running a Sybase SQL server 24/7 though it is only in use 7:30am - 5:30pm Monday thru Friday. However, since it has successfully backed up with the SQL running then that shouldn't be the issue. One the client side there is nothing else running now that we've turned off Norton Anti-Virus.

 

 

 

Amy:

 

Also, isolate the variables - a crossover cable, a different backup computer.... See if the problem follows your troubleshooting steps. For example, does the problem go away with a crossover cable? If yes, then the problem has been isolated to an issue! With the server or the client. If no, then the problem has been isolated to the network.

 

 

 

Tom:

 

We've not yet tried the crossover cable as we've not seen an errors reported on the Cisco ports that these two machines are on though we may try that soon. I think I'll first try uninstalling and then reinstalling the client and perhaps locking the ports at the Cisco and at each of the machine to 1000mbps. Again though I'll stress that when it works it works very well and since there are no network errors reported I really don't think it's a network problem but to satisfy you we'll probably try the crossover cable.

 

 

 

 

Link to comment
Share on other sites

Finally the backup of the server File is working! That's 4 nights in a row, a new record! What did I do? I changed three things in one day so take your pick.

 

 

 

1.] Forced the NICs on both the File server and Apps server to 1000mbps (1Gig). They were already autonegotiating at that speed but I feel it best to lock them down since their ports on the Cisco was already locked. I should say though that neither the Cisco nor the NIC cards reported any errors.

 

 

 

2.] The Apps server that Retro was running on has two NICs. I used the NIC software to "team" the cards together to make them act as one card. Seems if this was the problem then I would have been having difficulties backing up a lot of workstations but who knows for sure.

 

 

 

3.] And I think this is most likely what fixed the problem. I uninstalled the Retrospect Client, rebooted and then reinstalling the Retrospect Client and then rebooted again.

 

 

 

We've had four nights of success so I hope the problem is truly solved. We had another workstation client that was getting backed up but very slowly. On his computer I also locked his port to 100mbps and also did an uninstall and reinstall of the client and now he's backing up normally. But there again I changed two variables so who knows for sure which one fixed the problem?

 

 

 

Thanks for your help.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...