我在工作中接手了一项传输工作，这给我带来了一些问题。我们正在使用 RoboCopy 将文件从一个位置传输到另一个位置。该脚本确实可以很好地复制文件，但设置为扫描源文件夹 15 次以查找文件。源位置有大约 200 GB 的文件和文件夹。每天可能有 1 GB 的更改需要传输。
任务似乎永远无法完成。查看作业日志，我可以看到仍在扫描文件夹以查找更改。我已将重试次数从 15 次更改为 5 次，以查看是否会发生变化，但仍然面临同样的问题。
基于此，我的问题是使用 Robocopy 扫描 200 GB 的文件。它会扫描每个目录以查找新更改吗？还是可以将其设置为仅扫描时间戳更改的文件夹？
答案1
是的，robocopy 将检查每个文件。但是，将作业拆分为几个“较小”的作业（如果必须的话）将缓解耗时过长的问题。只需确保您的目标也设置为下一级。然后只需将它们安排为单独的批处理文件，您肯定会缩短时间。
如果您的路径名很长，您实际上也可以对它们执行上述操作，但是，如果它们到处都是，创建 100 多个单独的作业将适得其反。如果它们在同一个树结构内，请创建一个从子目录进一步向下开始的批处理，然后您可以在复制其余结构的批处理文件中排除它，如果这有意义的话。排除文件夹的开关是 /XD dir（因此，它看起来像 /XD \server\share\sub1\sub2\sub3），这肯定会缩短您的路径名。有一件事，您是否使用 /W:1 /R:1（等待时间，重试）？默认值为 30 秒，重试次数为一百万次！- 甚至不要执行 /W:10 /R:10，因为您可能会为每个失败的复制额外增加 100 秒。
最重要的是，在运行此命令之前，请确保您使用 /LOG:logfile（或 /LOG+:logfile 附加到现有文件）和 /L，它将以 LIST-ONLY 的形式运行命令，这样您就可以发现任何问题。您还可以切换到 Robocopy GUI 或 robocopy 替代品，我以前尝试过解决这样的问题，例如 secure copy quest、gs richcopy360 和 teracopy，，，，所有解决方案都适合您，只需告知我们您的问题是否解决了？
答案2
我建议您尝试使用 Robocopy GUI 实用程序重新配置计划，以确保没有配置问题： https://technet.microsoft.com/en-us/magazine/2009.04.utilityspotlight.aspx
要了解它是如何工作的，请查看此博客： https://technet.microsoft.com/en-us/magazine/ee851678.aspx
答案3
是的，robocopy 将遍历整个树，即使源和目标副本上的“上次修改”时间戳相同，它也会进入并扫描目录。它有一些基于时间戳的复制逻辑，但仅适用于文件。
鉴于您说的是“位置到位置”，您的瓶颈几乎肯定不是扫描本身，而是远程树的遍历。您可能想要做的是查看 robocopy 替代方案，这些替代方案可以在运行之间缓存目标树的内容，或者工作方式类似于rsync，即在连接的两端运行两个协作实例。
对于前一种选择，我思考SuperFlexibleFileSynchronizer 曾经有这个功能，我知道 Bvckup 2 也有这个功能。对于后者，也许你可以尝试使用 rsync 本身？
答案4
通过robocopy /???，您可以获得所有选项的解释。
我的备份脚本使用以下参数可能对您有帮助：
/FFT /E /R:5 /W:30 /XO
/FFT采用 2 秒粒度的时间戳/E复制子目录/R:5最多重试 5 次/W:30每次重试之间等待 30 秒/XO仅复制较新的文件
在启动 robocopy 之前暂停防病毒软件可能会有所帮助。这可能会对整体性能产生很大影响。