Alternativa para robocopy / MIR

Question

Executamos vários aplicativos da web que armazenam muitos dados locais em pequenos arquivos xml. Uma parte de nossa estratégia de backup / recuperação é produzir um espelho local do sistema de arquivos por meio de uma VPN para o centro de hospedagem.

A conexão VPN é somente via ADSL de 12Mbps e, embora haja muitos arquivos e diretórios, o número real de arquivos que são alterados é muito pequeno.

Embora a largura de banda seja provavelmente um problema, estou vendo resultados como a saída abaixo. O robocopy / MIR demorou 5 horas para ser executado, mas apenas 30 minutos para realizar a cópia.

Alguém tem alguma sugestão sobre como melhorar isso? As 5 horas agora estão muito próximas e, se não conseguirmos encontrar uma maneira de acelerar isso, teremos que encontrar uma solução completamente diferente.

            Total    Copied   Skipped  Mismatch    FAILED    Extras
 Dirs :     17625      6618     11007         0         0         0
Files :   1112430      1223   1111207         0         0         0
Bytes :  57.451 g  192.25 m  57.263 g         0         0         0
Times :   5:01:23   0:35:55                       0:00:00   4:25:27

Speed :               93509 Bytes/sec.
Speed :               5.350 MegaBytes/min.

Ended : Fri Apr 16 05:54:23 2010

    

Answer 1

O Robocopy terá que enumerar todos os arquivos locais e remotos primeiro, para determinar quais precisam ser transferidos. É mais provável que isso esteja demorando.

E se você redefinir o atributo Arquivo de arquivamento após um backup bem-sucedido:

attrib -a /s *

Em seguida, toda vez que um arquivo for gravado, o bit de arquivamento será definido automaticamente. Da próxima vez, você pode dizer ao Robocopy para arquivar apenas arquivos com o sinalizador A:

robocopy source destination /mir /a

Eu não testei isso, mas acredito que deve ser mais rápido, pois o Robocopy terá muito menos arquivos para processar.

Outra ideia seria executar um trabalho agendado no servidor remoto (se isso for possível) para zipar toda a estrutura de diretório e depois copiar o arquivo zip resultante sobre a VPN. O XML compactará bem e a cópia de um único arquivo será muito mais eficiente em um link de alta latência.

    

Answer 2

Eu uso o rsync para Windows para copiar em conexão de banda larga. É supostamente um sistema de cópia delta que copia apenas as alterações de cada arquivo, enquanto o robocopy copia o arquivo inteiro se ele tiver mudado um bit. (eu me pergunto às vezes se isso realmente acontece)

Você também pode usar o robocopy / mon: x switch e executá-lo permanentemente. Isso será executado quando o robocopy visualizar x mudanças no sistema de arquivos. Se for executado com muita frequência, apenas um pequeno número de alterações ocorrerá.

Você pode usar o recurso de replicação de arquivos no Windows Server, usar um caminho DFS para cada pasta e definir a pasta local e remota como um destino.

    

Answer 3

Eu segundo a recomendação de Charles Gargent para o rsync. Eu uso o rsync sobre SSH com o Cygwin. Se bem me lembro, há um executável não dependente de cygwin disponível.

Um benefício enorme que o rsync tem sobre o robocopy é que um agente rsync será gerado no lado remoto para fazer o processamento nesse fim. O agente remoto pode inspecionar o sistema de arquivos remoto sem precisar trazer todos os detalhes do arquivo de volta à sua máquina local para processamento. Isso é muito, muito mais rápido do que o robocopy, e é provavelmente o que está por trás do atraso de 5 horas.

Você também pode usar compactação com rsync sobre ssh, o que pode acelerar ainda mais as coisas.

Cuidado, no entanto, que as ACLs do sistema de arquivos Cygwin e as ACLs do Windows não funcionam bem juntas. Se você precisar de uma cópia perfeita de ACLs, o rsync pode não ser para você. Eu tive que escrever um script para executar o xcacls para "limpar" as permissões dos meus arquivos depois de copiá-los.

    

Answer 4

Apenas algumas notas sobre o uso de attrib-a / s para contornar o déficit de robocopy. Se você for usar essa solução, execute-o ANTES de executar o backup completo. ie. Um backup completo geralmente leva muito tempo e alguns dos arquivos podem ter mudado entre quando foram armazenados em backup e quando você começa a executar o atributo posteriormente, o que pode significar a falta dessas alterações em cópias posteriores.

A segunda observação sobre essa solução é que ela só funciona bem se as cópias não forem filtradas. Se você filtrar seus processos de backup ou robocopy para evitar arquivos temporários e lixo semelhante, não haverá uma maneira fácil de verificar se o attrib examina apenas o arquivo que o processo de cópia examina. Isso é; você está mudando o atributo em arquivos que você não está realmente copiando - e isso não é realmente uma boa idéia.

Fascinar esse robocopy parece incapaz de criar um backup completo tradicional ... ou não em uma única execução. Você pode fazê-lo, executando-o duas vezes. Uma vez para copiar tudo e, em seguida, novamente com / M para copiar e desta vez realmente redefinir os bits de arquivo. O que é um PITA.

    

Answer 5

Os comentários de XYZ sobre a desvantagem de usar o ATTRIB são úteis, no entanto, não é suficiente simplesmente seguir um comando robocopy / MIR com um comando robocopy / COPY / M para redefinir os bits de archive seletivamente. O Robocopy não irá redefinir o bit a menos que ele realmente copie o arquivo e (por padrão) ele não copiará os arquivos 'Same'. Portanto,

Destino de origem do ROBOCOPY / MIR

Destino de origem do ROBOCOPY / COPY / M

deixará o bit de arquivo de muitos arquivos na fonte inalterados. (Eu gostaria que não fosse verdade.)

É improvável que o código-fonte do Robocopy seja modificado ainda mais, mas eu gostaria que os autores tivessem fornecido um 'this' para / MIR redefinir os bits do arquivo de uma só vez (por exemplo, / MIR: A). Isso é importante principalmente para iniciar backups em um novo sistema, mas, de qualquer forma, isso demonstra que o robocopy / MIR não é uma solução de backup 'completa'.