rsync com --hard-links congela

6

Eu tenho um grande diretório chamado servers , que contém muitos hard-links feitos por rsnapshot . Isso significa que a estrutura é mais ou menos como:

./servers
./servers/daily.0
./servers/daily.0/file1
./servers/daily.0/file2
./servers/daily.0/file3
./servers/daily.1
./servers/daily.1/file1
./servers/daily.1/file2
./servers/daily.1/file3
...

Os instantâneos foram criados com rsnapshot de uma maneira que economiza espaço: se /servers/daily.0/file1 for igual a /servers/daily.1/file1 , ambos apontarão para o mesmo inode usando hard-link, em vez de copiar apenas um instantâneo completo a cada cycle./servers/daily.0/file1/servers/daily.0/file1

Eu tentei copiá-lo com a estrutura de links físicos, a fim de economizar espaço na unidade de destino, usando:

nohup time rsync -avr --remove-source-files --hard-links servers /old_backups

Após algum tempo, o rsync congela - nenhuma nova linha é adicionada ao arquivo nohup.out , e nenhum arquivo parece mover-se de uma unidade para outra. Remover o nohup não resolveu o problema.

Alguma ideia do que está errado?

Adam

    
por Adam Matan 30.11.2010 / 13:34

3 respostas

9

Minha resposta, que eu dou de uma experiência suada, é: não faça isso. Não tente copiar uma hierarquia de diretórios que faça uso intenso de links físicos, como um criado usando rsnapshot ou rsync --link-dest ou similar. Não funcionará em nada além de pequenos conjuntos de dados. Pelo menos, não de forma confiável. (Sua milhagem pode variar, é claro; talvez seus conjuntos de dados de backup sejam muito menores do que os meus.)

O problema com o uso de rsync --hard-links para recriar a estrutura de arquivos com link físico no lado do destino é que a descoberta dos hard-links no lado da origem é hard . rsync tem que construir um mapa de inodes na memória para encontrar os hard-links, e a menos que sua fonte tenha relativamente poucos arquivos, isso pode e irá explodir. No meu caso, quando soube desse problema e procurava soluções alternativas, tentei cp -a , que também deveria preservar a estrutura de arquivos rígidos dos arquivos no destino. Ele se agitou por um longo tempo e finalmente morreu (com um segfault, ou algo parecido).

Minha recomendação é reservar uma partição inteira para o seu rsnapshot backup. Quando estiver cheio, coloque outra partição online. É muito mais fácil movimentar conjuntos de dados com links pesados como partições inteiras, em vez de arquivos individuais.

    
por 01.12.2010 / 04:16
7

No ponto em que o rsync parece travar, ele está suspenso ou está ocupado? Verifique se há atividade da CPU com top e atividade do disco com iotop -o .

Pode estar ocupado a copiar um ficheiro grande. Você veria isso em iotop ou similar, ou na exibição do rsync se você o executasse com a opção --progress .

Também pode estar ocupado pesquisando listas de inodes para verificar arquivos vinculados. Se a recursão incremental estiver sendo usada, que é o padrão para transferências recursivas na maioria dos casos se o cliente e o servidor tiverem rsync v3.0.0 ou mais recente, ele pode ter acessado um diretório com muitos arquivos e executar a verificação de link entre todos os arquivos nele e todos aqueles encontrados anteriormente. A opção --hard-links pode ser muito muito CPU intensiva em grandes conjuntos de arquivos (é por isso que ela não está incluída na lista de opções sugeridas pela opção --archive geral). Isso se manifestará como um alto uso da CPU no momento em que o rsync parece pausado / suspenso.

    
por 30.11.2010 / 14:52
-1

Eu tive o mesmo problema. Meu problema foi resolvido adicionando a opção --no-inc-recursive .

    
por 15.02.2017 / 09:14