Rsync -avzHP segue hardlinks em vez de copiá-los como hardlinks

Question

Eu uso o rsnapshot para criar backups de hora em hora / diários / semanais / mensais do meu compartilhamento de "trabalho". Agora estou tentando copiar todo o diretório de backup em uma unidade externa usando o rsync.

Eu usei este comando / parâmetros dentro de uma sessão de tela (sim, o rsync-exclude.txt está no diretório do qual eu rodei o comando)

rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/;

A coisa toda está rodando em um QNAP TS-439, a unidade interna é um único disco (sem RAID) formatado EXT4, o drive externo é formatado EXT3.

O que acontece é: o Rsync segue todos os hardlinks e copia o arquivo real em vez de recriar o hardlink atualizado na unidade externa. Eu não reconheci isso imediatamente, então o drive externo acabou com lixo xxx cópias dos mesmos arquivos.

O que eu quero alcançar é: copiar toda a estrutura de arquivos gerada pelo rsnapshot para a unidade externa, mantendo os hardlinks para economizar espaço. Nota: Isso não deve necessariamente ser feito usando o rsync.

Obrigado pelas suas ideias e tempo. Eu apreciaria sua ajuda, grande momento.

Atualização: Eu aprendi que o rsnapshot não está usando links simbólicos, ele está usando hardlinks então agora eu uso a opção -H que deve preservar a estrutura do hardlink de acordo com Rsnapshot para vários destinos (ou manter estrutura de links rígidos) mas ainda assim não funcionará ... o que estou sentindo falta aqui?

Atualização 2: encontrei outra opinião / declaração sobre esse tópico aqui: rsync com --hard-links congela Steven Monday sugere não tentar rsync grandes estruturas de arquivos contendo hardlinks, já que consome muita memória e é uma tarefa difícil para o rsync. Então provavelmente uma solução melhor seria fazer um .img da estrutura de dados que estou tentando fazer backup. O que você acha?

    

Answer 1

A opção rsync (ou -H ) do comando --hard-link fará, em teoria, o que você está tentando realizar, o que é, em resumo: criar uma cópia do seu sistema de arquivos que preserva a estrutura vinculada do original. Como mencionei na minha resposta a outra pergunta semelhante , essa opção está fadada ao fracasso quando o sistema de arquivos de origem ultrapassar um certo limite da complexidade do link físico.

A localização precisa desse limiar pode depender da sua RAM e do número total de links físicos (e provavelmente várias outras coisas), mas descobri que não há sentido em tentar defini-lo com precisão. O que realmente importa é que o limite é muito fácil de cruzar em situações reais, e você não saberá que você cruzou, até o dia vem que você tenta executar um rsync -aH ou um cp -a que se esforça e eventualmente falha.

O que eu recomendo é o seguinte: Copie seu sistema de arquivos strongmente vinculado como uma unidade, não como arquivos. Ou seja, copie toda a partição do sistema de arquivos como uma grande bolha. Existem várias ferramentas disponíveis para fazer isso, mas a mais onipresente é a dd .

Com firmware de estoque, seu QNAP NAS deve ter dd integrado, bem como fdisk . Com fdisk , crie uma partição na unidade de destino que seja pelo menos tão grande quanto a partição de origem. Em seguida, use dd para criar uma cópia exata de sua partição de origem na partição de destino recém-criada.

Enquanto a cópia dd estiver em andamento, você deve garantir que nada mude no sistema de arquivos de origem, para que você não acabe com uma cópia corrompida no destino. Uma maneira de fazer isso é umount da fonte antes de iniciar o processo de cópia; Outra maneira é montar a fonte no modo somente leitura.

    

Answer 2

-l é para links simbólicos, por que faria alguma coisa por hardlinks?

(Desculpe, esta é uma resposta e não um comentário, ainda não tenho direitos de comentário e essa resposta precisou de uma resposta)

Outra nota que deve ser um comentário: isso é todo hardware nativo ou você está em uma montagem de rede VM?

Editar

ignore meu comentário anterior sobre o motivo pelo qual você está usando hardlinks, perdi o comentário rsnapshot .

Seria útil ter um teste que primeiro testa o rsync entre o disco local de dois diretórios locais e, em seguida, o disco remoto. Este pequeno teste mostra a -H opção wokrs conforme o esperado. A opção -i para ls mostra os inodes, mostrando assim que os links foram preservados, sem cópias extras.

$ rsync -avzHP src/ dest
sending incremental file list
created directory dest
./
file111_prime.txt
           9 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/3)
file111.txt => file111_prime.txt

sent 156 bytes  received 59 bytes  430.00 bytes/sec
total size is 18  speedup is 0.08

$ ls -liR
.:
total 8
414044 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 dest
414031 drwxrwxr-x. 2 nhed nhed 4096 Feb 25 09:58 src

./dest:
total 8
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414046 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

./src:
total 8
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111_prime.txt
414032 -rw-rw-r--. 2 nhed nhed 9 Feb 25 09:57 file111.txt

Um teste subseqüente rsync -avzHP src/ host:/tmp para um host remoto ainda mantinha os hardlinks

    

Answer 3

Este é um tiro no escuro, mas se você não conseguir encontrar outra solução, sugiro tentar formatar o drive USB como EXT4. Talvez esse seja o problema: link

Given enough hard links in a source folder and a small enough destination volume, copying with rsync --hard-links can fail. Rsync fails by exhausting the maximum number of hard links on the destination <...> the real issue isn't rsync but instead the underlying file system.

    

Answer 4

Você já tentou adicionar a opção -l ?

Eu sei que a página de manual diz que está incluída em -a , mas as páginas de manual nem sempre são 100% precisas.