我正在停用一台用作文件服务器的旧 2003 服务器,并尝试将文件存储库迁移到新的 Windows Storage Server 2012 机箱中进行试运行。我正在使用 robocopy 复制文件,目前只是进行一些测试运行,看看在我们进行最终更改之前需要多长时间。
我第一次运行 robocopy 时提供了以下开关:选项:。/S /E /COPYALL /PURGE /MIR /MT:128 /R:100000 /W:30 它运行良好(虽然我不推荐 /r 和 /w 开关,因为它需要很长时间才能完成!)第二次我使用以下开关运行它(目标目录已经包含了我第一次运行它时源目标的副本,/MIR 将确保它已更新):选项:。/S /E /全部复制/清除/MIR /MT:128 /R:0 /W:0
这导致服务器在作业开始后约 5 分钟挂起。它完全挂起,我不得不手动关闭电源以重新启动它。日志并没有给我提供出错的详细信息 - 我以为是 /mt:128 导致了问题,但我第一次提供了该开关,这没问题。
第二次我将几个开关改为 /r:0 和 /w:0,尽管我不认为它们会导致它挂起。
最后,我选择 /MIR 是有问题的,因为目标之前已经从源复制过一次了——但我没想到会这样,因为我认为镜像的唯一潜在缺点是它会删除目标中不再存在于源中的文件。如果有人能解释一下出了什么问题,那将确保下次我尝试时不会出错。
编辑:我上面提到的开关取自 robocopy 日志文件,从某种意义上说,它们是我指定的开关的解释,这些开关是:/MIR /COPY:DATSOU /MT:128 /R /W
第二次编辑:有问题的服务器有双 NIC,使用 Windows Server 内置 NIC 组合进行组合。我觉得这是重要的信息,我最初发布问题时没有分享。想调查一下。有问题的 NIC 是 Intel(R) 82574L 千兆网络连接。NIC 团队是“Microsoft 网络适配器多路复用器驱动程序”。
答案1
听起来这肯定是网卡驱动程序的问题。要查看这是否是双网卡设置的错误,请将 IPG 参数调整为大约 20 毫秒并删除 /MT:128 参数(因为 /IPG 和 /MT 不兼容)。使用原始帖子中的“我指定的开关”行,它看起来会像这样。
/MIR /COPYALL /R /W /IPG:20 /Z
/IPG:20(数据包间间隙)将大大减慢传输速度,但能提供稳定性。
/Z(可重启模式)对于通过网络进行的复制非常重要,以防网络中断(由坏卡、驱动程序或实际网络问题引起),因为它允许复制从中断的地方继续。
如果成功完成,则说明您的网络驱动程序存在问题。问题在于您使用的任何驱动程序都无法处理 /IPG:0 的吞吐量。
NIC 驱动程序是服务器挂起的根本原因,而最彻底的解决办法是更换卡并重新运行导致其挂起的命令。除此之外,您可能还可以拔掉其中一个连接,这样就不会发生多路复用,然后运行产生错误的命令。
建议来自 technet 上的 cb42。
...ss64 很棒(只是说说而已!)http://ss64.com/nt/robocopy.html
答案2
在我看来,Robocopy A) 存在缺陷,B) 以某种方式挂接到内核,一旦出现缺陷,整个系统就会变得极不稳定。我们经常看到这种情况(尤其是使用 MT 选项时),在相当高速的 WAN 链路(20Mbps - 100Mbps)上进行同步时。所以我很确定这不是 NIC 驱动程序的流量问题 - 我们在生产中所做的滥用远比这严重得多,即使在 Cisco UCS / VMWare 5.5 上使用 10Gbps LAN 连接,我们也会见到这种情况,所有补丁都已更新,Robocopy v6.3.9600.17415 已于 2014 年 10 月 28 日发布。
如果有人能明确证明我们都在做一些愚蠢的事情,我会很高兴,但看起来微软只是在发布一些令人难以置信的危险代码。
答案3
为什么使用/S
?/E
它似乎是相反的。 和/E + /Purge
等于/Mirror
。而且我认为 /MT:128 太高了,你应该降低它。尝试:
/S /MIRROR /COPYALL /MT:64 /R:10 /W:60