RSYNC para backup incremental leva 3+ dias

Question

Eu criei uma solução de backup incremental que usa o RSYNC para fazer backup de alguns de nossos servidores. Eu estou usando PHP para executar arquivos de configuração para obter as informações de cada servidor que precisa de backup. O PHP então chama o RSYNC para manipular o backup remoto dos servidores, incrementalmente.

Isso funciona perfeitamente em todos os nossos servidores e leva apenas alguns minutos para terminar ... tudo, exceto um servidor. Este servidor tem muitos dados, e parece que o RSYNC simplesmente fica pendurado nele. Leva mais de 3 dias para fazer um único backup incremental. Meu palpite é que ele está preso na construção da lista de arquivos.

Quando executo o comando abaixo na pasta que quero fazer backup, aqui estão os resultados 'iused'.

df -i folder/
54176307

Isso é simplesmente dados demais para o RSYNC manipular? Eu deveria estar procurando outra alternativa? O servidor de backup está sendo executado na versão 3.0.8, no entanto, os clientes que estão sendo submetidos a backup estão todos executando o RSYNC 2.6.9. Você acha que atualizar tudo para a versão 3.0.8 faria a diferença e reduziria o tempo de backup de 3 dias para esse servidor?

Obrigado Jacob

    

Answer 1

Eu duvido que a atualização por si só forneça o tipo de melhoria que você está procurando. Às 72 horas, você provavelmente desejaria aumentar o desempenho em ordem de magnitude (7,2 horas). Se você está procurando por 2-3 horas, boa sorte sem um SSD e uma boa rede.

Com 55 milhões de inodes (assumindo aproximadamente o mesmo número de arquivos), você terá que reconsiderar seriamente sua abordagem. Primeiro, se você estiver usando uma variante ext, eu consideraria o benchmarking de um FS diferente.

Segundo, se você estiver usando um ext FS (digamos ext3 / 4), a primeira coisa que eu faço é desligar o atime! Com o atime ligado, toda vez que um arquivo é lido / visualizado, o sistema de arquivos precisa fazer uma pequena gravação no disco, pois atime significa "tempo de acesso". Ao desligá-lo, você perde a capacidade de ver quando um arquivo foi acessado, mas é assim que o cookie se desintegra. Se você estiver usando um disco SATA padrão, suponha que você pode fazer 100 IOs por segundo (IOPS). Cada gravação de acesso leva um desses (pior caso). Isso significa 100 arquivos por segundo apenas para verificar sua existência e, quando você o lê, está usando ainda mais IOPS. 55000000/100 = 550000s = 152 horas. Uma vez que você tenha descoberto nos algoritmos muito bons do kernel para mesclar as IOPS, provavelmente encontrou seu gargalo.

No seu / etc / fstab, use a opção de montagem:

noatime,nodiratime 

para desativar completamente o horário. Deixe de lado o nodiratime para deixar os tempos de acesso de diretórios. Se você tem muitos diretórios, recomendamos desativá-lo.

Eu aposto que isso sozinho ajudará dramaticamente.

Veja um exemplo de fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda1 during installation
UUID=66188c62-0d8c-46d8-a44f-8f673ca6ac98 /               ext4    errors=remount-ro,discard,noatime,nodiratime 0       1
# swap was on /dev/sda6 during installation
UUID=c3f40312-d6f9-4bb7-b426-602a4b7a6c47 none            swap    sw              0       0

    

Answer 2

Eu tenho alguns scripts que fazem algo do tipo. Acho que a solução certa é encontrar o sistema de arquivos em busca de coisas que foram alteradas desde o último backup e depois fazer o rsync para a "sincronização", mas não resolvi isso.

Em vez disso, o que eu tenho são 2 scripts 1 que localizam os diretórios de nível superior para backup e o outro que faz o backup de cada um deles em paralelo. Eu acho que com o armazenamento de arquivos NFS eu recebo uma alta utilização de CPU em torno de 10 rsyncs paralelos. Como o trabalho está próximo da CPU nesse ponto, enquanto um único rsync está mais próximo de 7% do cpu, eu uso xargs para executar cada trabalho individual, mas para executar 7 trabalhos simultaneamente com a opção -P.

Eu posso enviar um script por e-mail se alguém estiver interessado. Eles devem ser bem legíveis.