我计划每15分钟运行一次SQL日志备份，包括带有/ MIR选项的robocopy，使用CloudBerry到云存储卷上的存档文件夹。
有时在完全备份和慢速网络之后，完整备份存档副本在运行日志备份时尚未完成，我怀疑第二个robocopy现在也会尝试复制大型完整备份文件除了新的日志备份。
应该怎么办？如果重试标志设置为/ R：60，那么第二个实例是否应该以某种方式跳过已被另一个robocopy实例复制的文件，或者两个robocopy实例是否会相互重叠？或者必须在设置/ R：0选项的情况下运行第二个实例以跳过仍在复制的第一个文件吗？
答案 0 :(得分：0)
我知道这个答案有点晚了，我希望你找到一个解决方案，但这是我的2美分：
Robocopy可以选择“监视源”以进行更改，我认为这是/ MON和/ MOT选项。这样可以防止robocopy重新运行 - 它总是在本质上是热文件夹类型的场景中运行。
在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.
答案 1 :(得分：0)
虽然这是一个很老的问题，但我还没有找到合适的答案，但是仍然很有意义，所以这是我的发现：
我进行了一些测试，似乎RoboCopy拍摄了源目录和目标目录的快照，并比较了需要从快照点复制哪些文件。
这意味着，如果一个RoboCopy实例紧接着另一个实例启动，则这两个实例将相互冲突并覆盖，因为这两个实例都不知道目标目录中正在发生更改。
如果一个实例（实例A）试图复制另一个实例（实例B）正在复制的文件，它将出错并重试（如果使用/ R）或跳至下一个（如果使用/ R）： 0）。实例B完成文件操作后，它将尝试复制列表中的下一个文件，这将出错（如果实例A仍在复制它）或覆盖文件（如果实例A已经移至下一个文件）
因此，在出现问题的情况下，最可能的行为（假设网络速度和文件大小保持一定程度一致）是新的RoboCopy实例将覆盖列表开头的备份文件，而原始实例仍在复制列表中的最后一个文件。