Robocopy unreliable over network ?!!! be careful!

[nalooti]

Hi,

I use a lot robocopy to backup my data in a single W7 x64 from one disk to another and it works fine.

I tried to use it over network (average 20Mbps HomePlug) to backup my data from my W7 x64 PC to an XP. I run the command from the W7 PC (say D after connecting the folders that I have already shared on XP in order to copy data on them (say Z.

As long as the command goes to the end, everything is fine. But I suspect a bug after something stops (e.g. network outage) the command!!!

Specially I found a case where file copied on destination is corrupted and robocopy doesn't signal it !!!
I run the command on W7 (to copy to XP over network), then after some time in the middle I kill the command (by doing <ctrl> C). Robocopy should at least delete the file on destination that is not entirely copied (thus corrupted). But it doesn't so. And the second time I launch robocopy, it thinks that file is copied correctly and goes to the next file. Of course this file is corrupt because I stopped the copy process in the middle. You can only see it by opening the file because even the size is wrongly equal to the source file size!!!

I may use it wrongly in which case I'd be happy if someone help me find out how to correct it.
I tried that several times and each time my explorer on XP (destination) wasn't working correctly (used 100% CPU) right after I stopped the robocopy in the middle of a copy. So maybe the problem comes from my XP machine but anyway, robocopy should signal me there is a problem!

In any case, be extremely careful and check your backup!!!!!!

nalooti

 

[Ijack]

You do use the /Z switch so that robocopy restarts the copy at the point of failure, don't you?

If so, then I'm very surprised that you have problems as robocopy is specifically designed to be robust when copying over a network. I have never had any problems with it, and I used to use it to copy hundreds of thousands of files between servers.

 

[nalooti]

You do use the /Z switch so that robocopy restarts the copy at the point of failure, don't you?

If so, then I'm very surprised that you have problems as robocopy is specifically designed to be robust when copying over a network. I have never had any problems with it, and I used to use it to copy hundreds of thousands of files between servers.

Thanks for the reply. I'm pretty sure I use /Z switch but I'll check that soon and let you know. BTW does /Z switch have any effect when copying locally from disk to disk on a single machine ?

I ask this because I may have the same behavior when copying disk to disk if in the middle of the transfer I stop the command (by <ctrl>C).

Actually I need to stop and resume later voluntary when transfers take too long (either because of network bottleneck or high data volume). So I stop the command and relaunch it the next day hoping to achieve the whole backup in multiple instances rather than in one instance. This is specially true for the first time, this is less needed when doing updates (after changes in the source folder). Hopefully, I saw the problem so that I know I can throw my backups away and redo them in a clean way.

nalooti

 

[Ijack]

Yes, /Z should have the same effect locally.

 

[nalooti]

Yes, /Z should have the same effect locally.

iJack, thanks to you I saw in my scripts that I actually forgot the /Z switch.

thanks you
nalooti

 

[Ijack]

I'm not sure why it doesn't default to that behaviour. Why would you not want a failed copy to restart at the point of failure? I can only think it's to avoid the situation where an unresolvable problem means the copy keeps stalling at the same point.

 

[nalooti]

I'm not sure why it doesn't default to that behaviour. Why would you not want a failed copy to restart at the point of failure? I can only think it's to avoid the situation where an unresolvable problem means the copy keeps stalling at the same point.

I agree with you. Another reason may be that following the documentation, the /Z switch takes much more time for additional processing required to guarantee the reliability (although the bottleneck is elsewhere). But again, a copy function isn't worth its name if it doesn't guarantee the reliability. The best example is the traditional copy function. If you stop it for any reason in the middle, the destination file being not complete, it is erased automatically; that is what robocopy should behave even without /Z.

In my case, since I don't know where I stopped each time and which files may have been corrupted, I have to begin from scratch.

 

[inopower]

Sorry to bring up an old thread but:

This 'be careful' warning seems to be FUD.

1. I have tested this and all though robocopy leaves an incomplete and not subset (byte for byte) file in all my tests it OVERRIDES it when your run robocopy again and resume.
From Wikipedia

Robocopy is notable for capabilities above and beyond the built-in Windows copy and xcopy commands, including the following:
Ability to tolerate network interruptions and resume copying. (incomplete files are marked with a date stamp of 1980-01-01 and contain a recovery record so Robocopy knows where to continue from)

That was what happened for me when I ran robocopy and then did ctrl c in the middle of a file being copyed, on running again the file was overwritten and the file's checksum matched the original.

2. Did nalooti check his files where corupt when he re ran robocopy again? Or where they just corrupt/incomplete on the first pass and he didn't try running robocopy again then checksuming a file or to to see if it worked out......



AFAIK using /z just means robocopy can continue copying the file on the next attempt rather than overriding it (which is faster for large files but more overhead for copying small files because robocopy has to track progress on a file).
You don't want to use /z unless your network is failing on large files (it's all about which is faster).

Please can someone tell me if they have a different experiences proving this wrong.
Are you still around nalooti?