Por que o robocopy fez com que meu servidor Windows 2012 fosse interrompido na noite passada?

Question

Eu estou no processo de descomissionar um servidor antigo do 2003, que atua como um servidor de arquivos, e estou apenas tentando executar um processo de migração do repositório de arquivos para uma nova caixa do Windows Storage Server 2012. Estou usando o robocopy para copiar os arquivos, e atualmente apenas faço algumas execuções de teste para ver quanto tempo demora, antes de fazermos a mudança final.

Na primeira vez que executei o robocopy, forneci as seguintes opções: Opções: . / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 100000 / W: 30 Ele correu bem (embora eu não recomendaria os switches / r e / w, pois demorará uma eternidade para ser concluído!) A segunda vez que eu corri com as seguintes opções (o diretório de destino já continha uma cópia do destino de origem da primeira vez que eu corri, / MIR irá garantir que ele seja atualizado): Opções: . / S / E / COPYALL / PURGE / MIR / MT: 128 / R: 0 / W: 0

Isso fez com que o servidor interrompesse cerca de 5 minutos após o início do trabalho. Ele desligou completamente e eu tive que ligar manualmente para reiniciá-lo. Os logs não estão me dando uma indicação enorme do que deu errado - os pensamentos eram de que / mt: 128 causaram problemas, mas eu forneci o switch pela primeira vez e estava tudo bem.

Na segunda vez, mudo alguns switches para / r: 0 e / w: 0, embora eu não imaginasse que eles o fizessem travar.

Finalmente, o fato de eu ter escolhido / MIR é problemático já que o destino já foi copiado da fonte uma vez antes - eu não teria pensado assim, já que eu achava que a única desvantagem potencial do espelhamento era que ele seria excluir arquivos no destino que não estão mais na origem. Se alguém puder lançar alguma luz sobre o que deu errado, isso vai garantir que não dê errado na próxima vez que eu tentar.

EDIT: os switches que eu mencionei acima são retirados do arquivo de log robocopy, e em certo sentido eles são uma interpretação dos switches que eu especifiquei, que foram: / MIR / COPY: DATSOU / MT: 128 / R / W

2a edição: o servidor em questão tem uma NIC dupla, agrupada usando a formação de NIC integrada do Windows Server. Eu sinto que essa é uma informação importante, que eu não compartilhei quando postei originalmente a pergunta. Gostaria de investigar isso. A NIC em questão é uma conexão de rede Intel (R) 82574L Gigabit. A equipe da NIC é 'Driver de multiplexador de adaptador de rede da Microsoft'.

    

Answer 1

Parece ser um problema no driver da placa de rede, com certeza. Para ver se este é um bug com sua configuração dual-nic, ajuste o parâmetro IPG para cerca de 20 milissegundos e remova seu parâmetro / MT: 128 (já que / IPG e / MT não são compatíveis). Usando sua linha de "switches que eu especifiquei" em sua postagem original, ficaria assim.

/MIR /COPYALL /R /W /IPG:20 /Z

O / IPG: 20 (intervalo entre pacotes) diminuirá consideravelmente a transmissão, mas proporciona estabilidade.

O / Z (modo reinicializável) é importante para cópias pela rede, em caso de interrupções de rede (causadas por cartões ruins, drivers ou por problemas reais de rede), porque permitirá que a cópia continue de onde parou .

Se isso for concluído com sucesso, você terá um problema com seu driver de rede. O problema seria que qualquer driver que você esteja usando não conseguirá lidar com a taxa de transferência de / IPG: 0.

O prego final no caixão para o driver da NIC ser a causa raiz do travamento do servidor seria substituir a placa e executar novamente o comando que a causou a interrupção. Além disso, você provavelmente também poderia desconectar uma das conexões para que a multiplexação não ocorresse e executar o comando que produziu o erro.

A sugestão veio do cb42 no technet.

link

... e ss64 rocks (apenas dizendo!) link

    

Answer 2

Parece-me que Robocopy é A) buggy, e B) conecta-se ao kernel de alguma forma que pode tornar todo o sistema inacreditavelmente instável quando se desvia. Vimos isso acontecer com bastante frequência (especialmente com a opção MT) ao sincronizar links de WAN razoavelmente de alta velocidade (20Mbps - 100Mbps). Então, eu tenho certeza que não é um driver NIC tendo problemas de volume de tráfego - nós fazemos coisas em produção que abusam deles muito mais do que isso, e vemos isso mesmo com conexões LAN de 10Gbps no Cisco UCS / VMWare 5.5, com tudo atualizado e Robocopy v6.3.9600.17415 datado de 28/10/2014.

Eu adoraria se alguém pudesse provar definitivamente que estamos todos fazendo algo estúpido, mas parece que a Microsoft está apenas lançando um código incrivelmente perigoso.

    

Answer 3

Por que você usa /S com /E ? Parece ser o oposto. E /E + /Purge é igual a /Mirror . E eu acho / MT: 128 é muito alto, você deve reduzi-lo. Experimente:

/S /MIRROR /COPYALL /MT:64 /R:10 /W:60