Você pode considerar a realização de uma rotação de log antes da sincronização. Ignore os arquivos ativos e faça backup dos arquivos. Você pode até mesmo tornar o rsync uma ação pós-rotatória depois que os logs são rotacionados normalmente.
Eu uso back-in-time para fazer backup da minha instalação do Linux. Ele serve como um wrapper avançado para o comando rsync .
Hoje tentei adicionar / var / log à lista de pastas para backup e isso causou sérios problemas de desempenho. O trabalho parece estar preso em um arquivo específico e o uso da CPU do processo rsync parent atinge 100%. Em seguida, usei lsof para ver qual arquivo causou o problema e parece ser o diretório /var/log .
Eu fiz algumas pesquisas e algumas experiências com as diferentes opções rsync e encontrei --checksum para ser o infrator. Sem o parâmetro, um backup incremental é concluído corretamente em minutos. Com ele, o processo irá parar quando rsync tentar sincronizar um arquivo de log em constante mudança. Isso faz sentido, mas ainda parece ser um bug para mim.
Estou usando a opção corretamente? Existe uma solução para isso?
Tenha em mente que a soma de verificação está lá apenas para verificar se a transferência de arquivos foi concluída com sucesso. um meio de garantir que o arquivo não seja corrompido, se você quiser.
Esta pode não ser a resposta que você está procurando, mas --checksum será lento. Não há maneira de contornar isso. Se eu fosse você, criaria um script bash rápido para compactar todos os seus logs antes de executar o backup.
Algo rápido seria suficiente:
#!/bin/sh
for file in /path/to/log/dir/*;
do;
zip 'basename $file'.zip *;
rm -f "$file";
done;
Em seguida, execute seu backup. Isso salvaria o rsync de criar somas de verificação de arquivos de log possivelmente grandes de qualquer maneira.
Seja legal ... Eu sei que não é a resposta que você estava procurando.
Boa sorte