Estou usando o rsync para fazer um backup em um NAS na minha rede local por SSH. No entanto, quando executando o rsync, estou achando que está ficando preso em determinados arquivos. O Rsync congelará completamente e se recusará a transferir quaisquer arquivos adicionais.
Eu então tenho que forçar um SIGKILL que faz com que todo o trabalho de rsync reinicie e fique preso no mesmo arquivo que causou a suspensão da última vez que o executei.
Eu tentei várias correções, mas até agora nenhuma funcionou. Eu originalmente pensei que isso está acontecendo por causa de algum problema de caractere ilegal entre o meu sistema local (OS X 10.11.3 com OS Extended FS e meu NAS rodando o Ubuntu Linux 14.04.1 com o drive ext4 para o backup). Eu notei que quando o rsync fica preso em um arquivo que ele geralmente tem, o nome do arquivo ou caminho geralmente tem um '&' nele 9/10 vezes.
No entanto, depois de observar os processos de rsync com lsof e htop no servidor, parece que o rsync (na maioria das vezes, mas não todos) falha em torno do mesmo ponto que o arquivo rsync do cliente trava. Tenho notado que, mesmo quando o rsync trava no lado do cliente, eu ainda recebo saída em lsof , mostrando que os arquivos no lado do servidor estão sendo acessados.
Este é o comando rsync que estou usando.
/usr/bin/rsync --bwlimit=1000 --verbose --rsync-path="sudo rsync" --archive --recursive --numeric-ids --human-readable --partial --progress --relative --itemize-changes --stats --files-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/backup_files --exclude-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/exclude -e "ssh -q -p 22 -i /Users/enwhat/.ssh/user" / [email protected]:/media/Backup/_Backup/Machine/
Exemplo de onde o rsync normalmente ficará preso:
<f+++++++ Volumes/Data/Users/user1/Pictures/2013_12_iPhone_Archive/IMG_6993.m4v
17.33M 63% 994.25kB/s 0:00:10
ou
<f+++++++ Volumes/Data/Users/user1/Documents/docs/Work/_Sort from USB backup drive/Drive/JOB/CD Album/AAA1834__Album&flyer_15_Years/2-Design/1-D-Visuals/stage 05/AAA_album_12_c.psd
96.40M 50% 1.55MB/s 0:01:00
Eu tentei remover --verbose --rsync-path="sudo rsync” --delete-during todos individualmente. Quando eu removo estes sinalizadores de argumento, o processo de rsync vai chegar a um determinado arquivo e depois travar.
Há mais alguma coisa em jogo aqui ou é muito provável que um caractere ilegal no nome do arquivo esteja causando um problema entre os tipos de FS?
Eu realmente achei que o Crashplan, que está rodando no servidor, pode estar consumindo muitos recursos e causando falha no rsync. Mas quando eu paro o serviço CrashPlan no servidor, os recursos são liberados, mas o rsync ainda falha nos mesmos arquivos. Esta é uma nota lateral e fora do escopo da questão, mas eu me pergunto se eu deveria abandonar o Crashplan e mudar para o Amazon Glacier como um serviço de backup, pois o Crashplan suga muito CPU e memória.