[jjo5555]

We have been using the excellent Robocopy for years to Mirror client data to cheap internal drives once per day as a secondary backup. It has saved our client's data many times and meant we have not had to restore from tape.

We tend to use the /MIR switch and with /R:3 /W:3 switches but we have one issue that we cannot work around and wondered if anyone could help?

When a source file is locked you get something like this:

Newer 4.8 g Outlook.pst
2009/07/16 08:52:14 ERROR 33 (0x00000021) Copying File E:\DATA\Work\Bob\outlook\Outlook.pst
The process cannot access the file because another process has locked a portion of the file.Waiting 3 seconds... Retrying...

This is fine and completely acceptable.

However, after the retries fail the corresponding destination is then deleted. This is not the ideal behaviour. We appreciate that the /MIR switch does delete destination files but we would like it not to do so if the file exists but simply cannot be copied in this run. We cannot see a way to achieve this.

Can anyone possibly advise?

[cluberti]

The problem with /MIR is that it's technically just the /PURGE command with the /E option, meaning if it cannot open a file to copy it, it treats it as if it doesn't exist in the file copy (which, I guess, technically it doesn't) so it mirrors that on the destination (removes the older version of a file it cannot copy).

The only real way around this is to either use a tool that doesn't work this way (perhaps look into xxcopy if you must use a command-line tool, which the /CLONE switch doesn't delete remote files it couldn't update, or at least didn't last I used it a few years ago) or look into a backup tool that backs up via a system driver that can bypass the lock (not preferred) or, better, uses volume shadow copies (preferred) on systems that implement it (like XP/2003 and newer).

[jjo5555]

Thanks for that.

Given the plethora of switches I was hoping that the Robocopy guys may have allowed for my scenario. I have got a command line way of creating a shadow copy of a volume and then using Robocopy but the overhead is quite large and I wanted to avoid it if at all possible.

This post has been edited by jjo5555: 04 August 2009 - 01:22 AM