Estou usando o rsync para fazer backup em um NAS na minha rede local por SSH. No entanto, ao executar o rsync, descobri que ele está travando em determinados arquivos. O Rsync irá congelar completamente e se recusar a transferir outros arquivos. Em seguida, tenho que forçar um SIGKILL que faz com que todo o trabalho rsync seja reiniciado e fique preso no mesmo arquivo que o travou da última vez que o executei.
Eu tentei várias correções, mas até agora nenhuma funcionou. Originalmente, pensei que isso estivesse acontecendo por causa de algum problema de caractere ilegal entre meu sistema local (OS X 10.11.3 com OS Extended FS e meu NAS executando Ubuntu Linux 14.04.1 com unidade ext4 para backup). Percebi que quando o rsync fica preso em um arquivo que normalmente possui, o nome do arquivo ou caminho geralmente contém um '&' 9/10 vezes.
No entanto, depois de observar os processos do rsync com lsofe htopno servidor, parece que o rsync (na maioria das vezes, mas não todas) trava no mesmo ponto em que o arquivo rsync do cliente trava. Percebi, porém, que mesmo quando o rsync trava no lado do cliente, ainda recebo uma saída mostrando lsofque 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 trava:
<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-duringtodos individualmente. Quando eu removo esses sinalizadores de argumento, o processo rsync chega a um determinado arquivo e depois trava.
Há algo mais em jogo aqui ou é bastante provável que um caractere ilegal no nome do arquivo esteja causando um problema entre os tipos de FS?
Eu pensei que o Crashplan, que está sendo executado no servidor, pode estar consumindo muitos recursos e causando o travamento do rsync. Mas quando paro o serviço CrashPlan no servidor, os recursos são liberados, mas o rsync ainda trava nos mesmos arquivos. Esta é uma observação lateral e está fora do escopo da questão, mas me pergunto se devo abandonar o Crashplan e mudar para o Amazon Glacier como um serviço de backup, já que o Crashplan consome muita CPU e memória.
Responder1
Não sei por que o rsync pode estar travado. Você pode tentar executar uma cópia regular nessa árvore de diretórios e ver se há algum tipo de erro de E/S. Executar uma verificação do sistema de arquivos não seria uma má ideia.
Quanto ao Amazon Glacier, sim, você pode usá-lo. O Duplicity oferece suporte ao S3 como destino de backup, e as regras de ciclo de vida do S3 permitem que você mova os arquivos para o Glacier automaticamente (configurado por meio do console da web do S3). Você precisa manter os arquivos de assinatura e manifesto no S3 (ou então a duplicidade não será capaz de recuperá-los), mas os arquivos de volume só serão necessários se você precisar extrair arquivos de backup, para que possam ser armazenados com segurança no Glacier. As regras do ciclo de vida exigem um prefixo conhecido, que não é o comportamento padrão da duplicidade, portanto, verifique as configurações dos parâmetros.