rsync muitos arquivos pequenos com nomes extensos de arquivos consomem muita largura de banda

Question

Eu tenho um servidor de armazenamento de arquivos que armazena arquivos no disco usando o hash sha256 do arquivo como o nome do arquivo, junto com a extensão do arquivo e em três níveis de diretórios, por exemplo, um arquivo PDF com sha256 hash AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A seria armazenado em um subdiretório como este:

<root>/AA/BB/AABB1F1C6FC86DB2DCA6FB0167DE8CF7288798271EA24B68D857CBC5CF8DC66A.pdf

Os arquivos serão adicionados à estrutura de diretórios, mas nunca serão excluídos ou modificados.

Eu mantenho uma cópia ativa dessa estrutura de arquivos usando uma tarefa cron executando a cada 10 minutos que usa o rsync para enviar os arquivos para um servidor remoto. Como os arquivos nunca são excluídos ou alterados depois de adicionados, na prática, ele envia apenas novos arquivos.

Descobri que a largura de banda usada pelo rsync apenas para comparar os dois diretórios (ou seja, não houve alterações) é de cerca de 11 MB e aumenta à medida que o número total de arquivos aumenta (148 207 no momento). Faz sentido - o rsync teria, na verdade, que enviar uma lista de todos os nomes de arquivos para o servidor remoto para descobrir quais estão faltando no servidor remoto.

Então, minha pergunta é: existe uma maneira de reduzir a largura de banda usada? Não precisa ser uma solução baseada em rsync, mas seria preferível. Eu estava pensando em limitar os arquivos que o rsync examina apenas para arquivos modificados recentemente, ou seja, modificados após a última sincronização, mas parece que isso não é recomendado: arquivos somente rsync criados ou modificados após uma data e hora

Alguma outra sugestão?

    

Answer 1

Não é recomendado para a maioria dos casos, mas, como seu objetivo é reduzir a largura de banda do cálculo da diferença, é apropriado. Considere o seguinte fluxo de script:

1. toque em um arquivo para ser sua "barra alta", isso precisa ser sistematicamente nomeado e não substituir sua última "barra alta", que agora é sua "barra baixa". O script irá transferir qualquer coisa com mtime entre as duas datas do arquivo. Note que você não deve renomear ou alterar os carimbos de data nesses arquivos.
2. use find com -newer <lowbarfile> ! -newer <highbarfile> para selecionar arquivos para transferência, canalizando para rsync como sua pergunta de referência.
3. todas as semanas (ou todas as noites), re-rsync o diretório inteiro para garantir que nada foi perdido. Obtenha um registro de e-mail dos arquivos transferidos dessa maneira para que você possa ver se estão ocorrendo problemas nas etapas anteriores.

Esta não é uma solução tão incrível quanto o inotifywatch, mas também não quebra depois de 8000 diretórios e sua hierarquia parece usar até 256 + 65536 dirs.

    

Answer 2

Para cada execução rsync precisa estabelecer uma listagem completa da estrutura de diretórios local e remota e calcular as diferenças, antes de determinar quais arquivos são criados recentemente e enviar esses novos arquivos. Isso é o que é "caro".

Você não mencionou qual é o sistema operacional do servidor de arquivos, mas no Linux você pode usar algo como inotofywatch para gerar um alerta em cada evento do sistema de arquivos que cria ou modifica um arquivo e usar esse evento como uma entrada para copiar os novos arquivos. Sua estrutura de diretórios hierárquica torna o inotifywatch um pouco caro.

No Windows você tem DFSR que faz aproximadamente o nome, ele também conecta o arquivo camada de sistema e é ainda mais inteligente no que diz respeito apenas a parte modificada de um arquivo é replicada, em vez de todo o arquivo.

    

Answer 3

Você pode executar o rsync com -e "ssh -C", compactando, assim, o túnel ssh em vez de apenas os dados, da mesma forma que ao executar com -z. Ou conectar pensou uma vpn que comprime o tráfego (openvpn pode fazer isso).