Chunking grandes transferências rsync?

Question

Usamos o rsync para atualizar um espelho do nosso servidor de arquivos primário para um servidor de backup externo localizado. Um dos problemas que temos atualmente é que o nosso servidor de arquivos tem > 1TB de arquivos menores (na faixa de 10 a 100kb) e quando estamos transferindo muitos dados, geralmente terminamos com a conexão sendo descartada várias horas após a transferência. O Rsync não tem um recurso de retomada / nova tentativa que simplesmente reconecta ao servidor para continuar onde parou - você precisa passar pelo processo de comparação de arquivos, que acaba sendo muito longo com a quantidade de arquivos que temos.

A solução recomendada é dividir sua grande transferência de rsync em uma série de transferências menores. Eu percebi que a melhor maneira de fazer isso é pela primeira letra dos nomes de diretório de nível superior, o que não nos dá uma distribuição perfeitamente uniforme, mas é bom o suficiente.

Gostaria de confirmar se minha metodologia para isso é sensata ou se há uma maneira mais simples de atingir a meta.

Para fazer isso, eu faço uma iteração de A-Z, a-z, 0-9 para escolher um caractere $prefix . Inicialmente eu estava pensando em apenas correr

rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/

(- exclude "* .mp3" é apenas um exemplo, já que temos uma lista de exclusão mais longa para remover coisas como arquivos temporários)

O problema é que quaisquer diretórios de nível superior em dest / que não estejam mais presentes no src não serão escolhidos pelo --delete. Para contornar isso, estou tentando o seguinte:

rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/

Estou usando o show e hide over include e exclude , porque senão o --delete-excluded excluirá qualquer coisa que não corresponda ao prefixo $.

Esta é a maneira mais eficaz de dividir o rsync em partes menores? Existe uma ferramenta mais eficaz, ou uma bandeira que eu perdi, que pode tornar isso mais simples?

    

Answer 1

Minha solução para isso foi uma abordagem diferente de dois passos, onde eu troco algum espaço em disco. Eu rsync --only-write-batch no servidor, em seguida, rsync o próprio arquivo em lotes para o destino, em loop até que o rsync tenha êxito. Quando o lote estiver totalmente concluído, o rsync --read-batch no destino recria todas as alterações.

Existem alguns benefícios não intencionais para isso também:

• porque estou mais preocupado que o backup "exista" do que é "utilizável". Na verdade, não faço o lote de leitura no terminal de recebimento todo dia - na maioria das vezes o lote é relativamente pequeno

• Eu tenho experimentado com --checksum-seed = 1 ... Eu posso estar lendo mal a documentação, mas eu acho que isso torna os arquivos em lote mais sincronizáveis (ou seja, quando eu não faço o --Lista a lote em qualquer dia, o lote do dia seguinte sincroniza mais rápido porque o lote do dia anterior é uma boa base)

• Se o lote ficar muito grande para ser enviado "no tempo" pela Internet, poderei colocá-lo em uma unidade externa. No tempo, quero dizer que, se eu não conseguir pegar o lote e ler antes do início do backup do dia seguinte.

• Embora eu não faça isso pessoalmente, posso ter dois backups externos em locais separados e enviar o lote para os dois.

Answer 2

Não exatamente respondendo a sua pergunta, mas outra opção que uso com bastante frequência é fazer isso de duas maneiras: primeiro crie uma lista de arquivos, divida a lista de arquivos a serem transferidos e alimente a lista de arquivos em rsync / cpio / cp etc.

rsync --itemize-changes <rest of options> imprimirá uma lista de arquivos a serem transferidos com um monte de metadados úteis, a partir dessa saída é muito fácil extrair os nomes dos arquivos e fazer a cópia real com rsync --files-from ou outra ferramenta.

Pode ser útil para a sua situação - a retomada de uma transferência interrompida seria muito mais rápida.

    

Answer 3

Sugiro que você analise o problema de conexão, em vez de tentar resolvê-lo criando outro "problema".

Não é um comportamento comum. Você está usando rsync através de SSH ou rsyncd?

Até onde eu sei, a maioria das conexões "fechadas" ocorre quando não há dados sendo transferidos entre terminais.