6

We have a scheduled task that runs robocopy periodically to mirror a rather large folder structure from one server to another (thousands of folders, 100,000+ files, 50+ GB in size). There is a share on the receiving server where the mirror gets stored. We're running the task from the origin server connecting out to the share on the receiving end. Both servers run Windows Server 2003 and are connected to the same network switch (100Mbps).

The process will sometimes complete all the way through without error. More often than not, however, at some point during the process (seems random as to where), robocopy will fail with the error The specified network name is no longer available. It will wait 30 seconds and try the file again and eventually give up after a number of retries. Process will repeat at the next schedule interval and may complete... or not.

When this occurs I am not able to access the share at all on the destination server from anywhere on the network for up to 30 minutes. There is nothing else on the network using this share.

My question is what does this error mean specifically? Why is the share "dropping off" and becoming inaccessible? Is there a way to prevent it and get the file mirroring to be more stable?

Justin Scott
  • 8,748
  • 1
  • 27
  • 39

1 Answers1

3

Robocopy is merely reporting what Windows has told it, that the remote end is no longer available, which can be a right pain to debug.

If you have antivirus software on the machines do a test run with that disabled. It's possible that the AV scanner isn't keeping up properly and causes things to hang while it tries to catch up. If that works you may need to disable the AV scanner on at least one end for the duration of the transfer. Also ensure that there is no firewall involved that might misinterpret the traffic and cause the the connection to be broken.

As a side note, that's a lot of traffic over such low speed NICs. You might consider adding a 1GB NIC to each machine, possibly connected by a crossover cable if you have no suitable switch ports available, and having that traffic routed through those NICs.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
  • We do run AV on both servers. On source side it's disabled for the folders in question (our e-mail storage, actually) because the e-mail server has its own AV and they fight with one another. I'll see if we can exempt the receiving folder as well and see if that helps. There isn't a firewall between them or enabled on the servers, so I can rule that out. As for the speed, the NICs are actually GB, but the switch between them is 100Mbps. They're in a datacenter 50 miles from here, but if all else fails I'll see about a crossover cable next time I'm there. – Justin Scott Jun 16 '10 at 22:32
  • 1
    Went to check the AV on the receiving server and it was reporting that the connection from the source server's IP had been blocked for trying to write too many infected files over (from the mail server's quarantine folder). Good suggestion! I've exempted the receiving folder from scanning which should prevent it from happening again. Thanks for the tip! – Justin Scott Jun 16 '10 at 22:44
  • So your AV scanner reconfig'd a software firewall? Interesting. What AV is it? Also, where the "infected files" false positives, or are they truly infected? – BillN Jun 16 '10 at 23:12
  • 1
    It's McAfee VirusScan Enterprise. I'd forgotten that it has a feature where it will block access to network shares when it detects that a remote system is trying to write an infected file over the share. The files actually are infected files that our mail server has quarantined and are pending removal (there is a delay between quarantine and deletion to allow us to address any false positives from the scanner on the mail server, so we don't want the OS AV messing with those files). – Justin Scott Jun 16 '10 at 23:46