1

I have some SQL log backups scheduled to run every 15 minutes including a robocopy with the /MIR option, to an archive folder on a cloud storage volume using CloudBerry.

Sometimes after a Full backup, and a slow network, the full backup archive copy has not completed when the log backup is run, and I suspect a problem caused by the second robocopy now also trying to copy the large full backup file in addition to the new log backup.

What should happen? If the retry flag is set to /R:60, should the second instance somehow skip files already being copied by another robocopy instance, or will the two instances of robocopy step all over each other? Or must the second instance be run with the /R:0 option set to skip the first file still being copied?

user229044
  • 232,980
  • 40
  • 330
  • 338
Dave
  • 1,822
  • 2
  • 27
  • 36
  • 2
    This question appears to belong on [Super User](http://superuser.com/). – Andrew Morton May 19 '14 at 19:35
  • I don't think so. This is a practical detailed question that I am having a problem with and need an answer as to how robocopy really works. I need to know exactly what robocopy will do when two instances are running trying to mirror the same folder to the same destination. I think many are too arrogant and elitist here and live to find fault with others... – Dave May 19 '14 at 23:05

2 Answers2

0

I know this answer is a little late and I hope you found a solution but here are my 2 cents:

Robocopy has an option to "monitor a source" for changes, I think it's the /MON and /MOT options. this would prevent robocopy from rerunning- it would always run in what is essentially a hot folder type scenario.

From the help of robocopy:

         /MON:n :: MONitor source; run again when more than n changes seen.
         /MOT:m :: MOnitor source; run again in m minutes Time, if changed.
0

While this is quite an old question, I have not found a proper answer and find it to still be relevant, so here are my findings:

I ran a couple of tests and it seems that RoboCopy takes a snapshot of the source and destination directories and compares which files need to be copied from the point of the snapshot.

This means that if one RoboCopy instance starts immediately after another, the two instances will keep clashing and overwriting each other, as neither of the instances are aware that changes are happening in the destination directory.

If one instance (instance A) attempts to copy the same file that the other instance (instance B) is copying, it will error and either retry (if using /R) or skip to the next (if using /R:0). Once instance B is finished with the file it will then try to copy the next file on the list, which will either error (if instance A is still copying it) or overwrite the file (if instance A already moved on to the next file).

So in the case of the question, the most likely behavior (assuming network speed and file sizes remain somewhat consistent) is that the new instance of RoboCopy will overwrite the backup files in the beginning of the list while the original instance is still copying the last files on the list.