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

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

Eu usei esse comando / parâmetros em uma sessão de tela (sim, o rsync-exclude.txt está no diretório em que executo o comando)

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

A coisa toda está sendo executada em um QNAP TS-439, a unidade interna é um EXT4 formatado em um único disco (sem RAID), a unidade externa está formatada em 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. Como não reconheci isso imediatamente, a unidade externa acabou com uma lixeira com 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 por suas idéias e tempo. Agradeço sua ajuda, grande momento.

Atualização: eu aprendi que o rsnapshot não está usando links simbólicos, está usando hardlinks, então agora uso a opção -H, que deve preservar a estrutura do hardlink de acordo com o Rsnapshot para vários destinos (ou manter a estrutura dos hard links), mas ainda não funcionará ... O que estou perdendo 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 estruturas de arquivos grandes contendo hardlinks, pois absorve muita memória e é uma tarefa difícil para o rsync. Portanto, provavelmente uma solução melhor seria criar um .img da estrutura de dados que estou tentando fazer backup. O que você acha?

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

A localização precisa desse limite pode depender da sua RAM e do número total de links físicos (e provavelmente de várias outras coisas), mas descobri que não há sentido em defini-lo com precisão. O que realmente importa é que o limite é por demais fácil cruzar em situações do mundo real, e você não vai saber que você tem atravessado, até o dia em que você tenta executar um rsync -aHou uma cp -aque as lutas e eventualmente falhar .

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

Com o firmware padrão, o QNAP NAS também deve ter sido ddincorporado 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 ddpara criar uma cópia exata da sua partição de origem na partição de destino recém-criada.

Enquanto a ddcópia estiver em andamento, você deve garantir que nada seja alterado no sistema de arquivos de origem, para que não ocorra uma cópia corrompida no destino. Uma maneira de fazer isso é com umounta fonte antes de iniciar o processo de cópia; outra maneira é montar a fonte no modo somente leitura.

-l é para links simbólicos, por que faria algo pelos links físicos?

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

Outra observação que deve ser um comentário: esse é todo o hardware nativo ou você está em uma VM montada na rede?

Editar

ignore meu comentário anterior sobre por que você está usando hardlinks, eu perdi o rsnapshotcomentário.

Seria útil fazer um teste que primeiro teste o rsync entre dois diretórios locais, disco local e depois no disco remoto. Este pequeno teste mostra a -Hopção wokrs conforme o esperado. A -iopção para lsmostra 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 subsequente rsync -avzHP src/ host:/tmppara um host remoto ainda mantinha os hardlinks

Este é um tiro no escuro, mas se você não encontrar outra solução, sugiro tentar formatar a unidade USB como EXT4. Talvez este seja o problema: https://bugzilla.samba.org/show_bug.cgi?id=7670

Dado o número suficiente de links físicos em uma pasta de origem e de um volume de destino pequeno o suficiente, a cópia com o rsync --hard-links pode falhar. O Rsync falha ao esgotar o número máximo de links físicos no destino <...> o problema real não é o rsync, mas o sistema de arquivos subjacente.

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

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