Usamos o rsync para atualizar um espelho do nosso servidor de arquivos primário para um servidor de backup externo. Um dos problemas que temos atualmente é que nosso servidor de arquivos tem mais de 1 TB de arquivos menores (na faixa de 10 a 100 KB) e, quando transferimos tantos dados, muitas vezes acabamos com a conexão caindo várias horas depois. a transferência. O Rsync não possui um recurso de retomada/nova tentativa que simplesmente se reconecta ao servidor para continuar de onde parou - você precisa passar pelo processo de comparação de arquivos, que acaba sendo muito demorado com a quantidade de arquivos que temos.
A solução recomendada é dividir sua grande transferência rsync em uma série de transferências menores. Achei que a melhor maneira de fazer isso é pela primeira letra dos nomes dos diretórios 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 fazer isso é sensata ou se existe uma maneira mais simples de atingir o objetivo.
Para fazer isso, eu itero por AZ, az, 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, pois temos uma lista de exclusões mais longa para remover coisas como arquivos temporários)
O problema com isso é que quaisquer diretórios de nível superior em dest/ que não estejam mais presentes em src não serão capturados por --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 showand hideover includeand exclude, porque caso contrário o --delete-excluded excluirá qualquer coisa que não corresponda ao $prefix.
Esta é a maneira mais eficaz de dividir o rsync em partes menores? Existe uma ferramenta mais eficaz, ou um sinalizador que perdi, que possa tornar isso mais simples?
Responder1
Minha solução para isso foi uma abordagem diferente de duas passagens, onde troco algum espaço em disco. Eu faço rsync --only-write-batch no servidor e, em seguida, sincronizo novamente o próprio arquivo em lote para o destino, fazendo um loop até que o rsync seja bem-sucedido. Quando o lote terminar totalmente, rsync --read-batch no destino recriará todas as alterações.
Existem alguns benefícios não intencionais nisso para mim também:
porque estou mais preocupado com o fato de o backup "existir" do que ser "utilizável". Na verdade, não faço o lote de leitura no recebimento todos os dias - na maioria das vezes o lote é relativamente pequeno
Tenho experimentado --checksum-seed=1 ... Posso estar lendo mal a documentação, mas acho que isso torna os arquivos em lote mais sincronizáveis (ou seja, quando não faço o --read-batch any determinado dia, o lote do dia seguinte será sincronizado mais rapidamente porque o lote do dia anterior é uma boa base)
se o lote ficar muito grande para ser enviado "a tempo" pela Internet, posso colocá-lo em uma unidade externa. Por dentro do prazo, quero dizer que, se não conseguir terminar o lote e lê-lo antes do início do backup do dia seguinte.
embora eu não faça isso pessoalmente, eu poderia ter dois backups externos em locais separados e enviar o lote para ambos.
Responder2
Não respondendo exatamente à sua pergunta, mas outra opção que uso com frequência é fazer isso em uma abordagem de duas etapas: primeiro crie uma lista de arquivos, depois 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 vários metadados úteis. A partir dessa saída, é bastante fácil extrair os nomes dos arquivos e fazer a cópia real com uma rsync --files-fromou outra ferramenta.
Pode ser útil para a sua situação - retomar de uma transferência interrompida seria muito mais rápido.
Responder3
Eu sugiro que você dê uma olhada no problema de conexão, em vez de tentar resolvê-lo criando outro "problema".
Não é um comportamento comum. Você está usando o rsync por meio de SSH ou rsyncd?
Pelo que eu sei, a maioria das conexões "fechadas" ocorre quando não há transferência de dados entre os terminais.