我正在退役一个旧的2003服务器，它充当一个文件服务器，我只是试图将文件存储库迁移到新的Windows Storage Server 2012中。 我正在使用robocopy复制文件，目前只做了一些testing，看看需要多长时间，然后再进行最后的修改。
我第一次运行robocopy时，提供了以下开关：选项： 。 / S / E / COPYALL / PURGE / MIR / MT：128 / R：100000 / W：30它运行良好（尽pipe我不会推荐/ r和/ w开关，因为它需要永久完成！第二次我用下面的开关运行它（目标目录已经包含了从第一次运行它的源目标的副本，/ MIR将确保它的更新）：选项： 。 / S / E / COPYALL / PURGE / MIR / MT：128 / R：0 / W：0
这导致服务器在作业开始后大约5分钟挂起。 它完全挂起，我不得不手动重新启动它重新启动它。 日志并没有给我一个很大的指示，说明什么地方出了问题 – 想法是造成了问题，但是我第一次提供了这个开关，那很好。
第二次，我改变了几个开关到/ r：0和/ w：0，虽然我不会想象他们会导致它挂起。
最后是我select/ MIR的问题，因为目的地已经被从源头复制过一次 – 我不会这么想，尽pipe我认为镜像的唯一潜在缺点是它会删除文件目的地不在源头。 如果有人能够清楚地发现问题出在什么地方，那么下次我尝试一下就不会出问题了。
编辑：我上面提到的开关取自robocopy日志文件，在某种意义上它们是我指定的开关的解释，它们是：/ MIR / COPY：DATSOU / MT：128 / R / W
第二编辑：有问题的服务器有一个双网卡，使用Windows Server内置NIC组合。 我觉得这是重要的信息，当我最初发布这个问题的时候，我并没有分享这些信息。 想调查一下。 所讨论的NIC是英特尔（R）82574L千兆networking连接。 NIC团队是“微软networking适配器复用器驱动程序”。
这听起来像是一个网卡驱动程序的问题。 要查看这是否是双nic安装的错误，请将IPG参数调整为大约20毫秒，并删除/ MT：128参数（因为/ IPG和/ MT不兼容）。 使用你的“开关我指定”行在你原来的职位，它会看起来像这样。
/MIR /COPYALL /R /W /IPG:20 /Z / IPG：20（数据包间隔）将大大减缓传输，但提供稳定性。
/ Z（可重新启动模式）对于networking上的副本非常重要，以防networking中断（由于卡，驱动程序或实际的networking问题导致），因为它允许副本从中断处继续。
如果成功完成，您的networking驱动程序出现问题。 问题是无论使用什么驱动程序都无法处理/ IPG的吞吐量：0。
NIC驱动程序棺材中的最后一个钉子是服务器挂起的根本原因是更换卡并重新运行导致挂起的命令。 除此之外，您也可以拔掉其中一个连接，以避免多路复用，并运行产生错误的命令。
build议来自cnet42 technet。
…和ss64岩石（只是说！） http://ss64.com/nt/robocopy.html
你为什么用/S和/E ？ 这似乎是相反的。 和/E + /Purge等于/Mirror 。 而我认为/ MT：128太高了，你应该减less它。 尝试：
/S /MIRROR /COPYALL /MT:64 /R:10 /W:60
在我看来，Robocopy是A）越野车，B）以某种方式挂钩到内核，当它出错时，可能会使整个系统变得难以置信地不稳定。 我们经常看到这种情况发生的频率（特别是MT选项），通过合理的高速WAN链路（20Mbps – 100Mbps）同步。 所以我非常确定这不是一个有驱动器stream量问题的网卡驱动程序 – 我们在生产环境中使用这些驱动程序比使用它的情况要严重得多，我们甚至在思科UCS / VMWare 5.5上使用10Gbps局域网连接也看到了这一点。和date为10/28/2014的Robocopy v6.3.9600.17415。
如果有人能够明确地certificate我们都在做一些愚蠢的事情，我会喜欢它的，但是看起来微软似乎只是提出了一些令人难以置信的危险代码。