Rsync -avzHP segue gli hardlink invece di copiarli come hardlink

Uso rsnapshot per creare backup orari / giornalieri / settimanali / mensili della mia condivisione "lavoro". Ora sto provando a copiare l'intera directory di backup su un'unità esterna usando rsync.

Ho usato questo comando / parametri all'interno di una sessione dello schermo (sì, rsync-exclude.txt si trova nella directory da cui eseguo il comando)

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

Il tutto è in esecuzione su un QNAP TS-439, l'unità interna è un disco singolo (senza RAID) formattato EXT4, l'unità esterna è formata EXT3.

Quello che succede è: Rsync segue ogni hardlink e copia il file effettivo invece di ricreare il hardlink aggiornato sul disco esterno. Non l'ho riconosciuto subito, quindi il disco esterno è stato cestinato con copie xxx degli stessi file.

Quello che voglio ottenere è: copiare l'intera struttura del file generata da rsnapshot sull'unità esterna mantenendo i collegamenti per risparmiare spazio. Nota: questo non deve necessariamente essere fatto utilizzando rsync.

Grazie per le tue idee e il tuo tempo. Apprezzerei il tuo aiuto, alla grande.

Aggiornamento: ho appreso che rsnapshot non sta usando symlink, sta usando hardlink, quindi ora uso l'opzione -H che dovrebbe preservare la struttura di hardlink secondo Rsnapshot su più destinazioni (o mantenere la struttura di hard link) ma non funzionerà comunque ... cosa mi sto perdendo qui?

Aggiornamento 2: Ho trovato un'altra opinione / dichiarazione su questo argomento qui: rsync con --hard-links si blocca Steven Monday suggerisce di non provare a risincronizzare strutture di file di grandi dimensioni contenenti hardlink, poiché assorbe molta memoria ed è un compito difficile per rsync. Quindi probabilmente una soluzione migliore sarebbe creare un .img della struttura dei dati che sto cercando di eseguire il backup. Cosa ne pensi?

L' opzione (o ) rsyncdel comando , in teoria, farà ciò che stai cercando di realizzare, vale a dire in breve: creare una copia del tuo filesystem che preservi la struttura strettamente collegata dell'originale. Come ho detto nella mia risposta a un'altra domanda simile , questa opzione è destinata a fallire una volta che il file system di origine supera una certa soglia di complessità del collegamento reale.-H--hard-links

La posizione precisa di quella soglia può dipendere dalla RAM e dal numero totale di collegamenti (e probabilmente da un numero di altre cose), ma ho scoperto che non ha senso cercare di definirla con precisione. Ciò che conta davvero è che la soglia è fin troppo facile da attraversare nelle situazioni del mondo reale e non saprai di averla superata, fino al giorno in cui provi a correre un rsync -aHo un cp -ache lotta e alla fine fallisce .

Quello che consiglio è questo: copia il tuo filesystem pesantemente collegato come una sola unità, non come file. Cioè, copia l'intera partizione del filesystem come un unico grande BLOB. Ci sono una serie di strumenti disponibili per farlo, ma il più onnipresente è dd.

Con il firmware di serie, anche il NAS QNAP dovrebbe essere ddintegrato fdisk. Con fdisk, creare una partizione sull'unità di destinazione che sia almeno grande quanto la partizione di origine. Quindi, utilizzare ddper creare una copia esatta della partizione di origine sulla partizione di destinazione appena creata.

Mentre la ddcopia è in corso, è necessario assicurarsi che nulla cambi nel file system di origine, per non finire con una copia danneggiata sulla destinazione. Un modo per farlo è umountl'origine prima di iniziare il processo di copia; un altro modo è montare la sorgente in modalità di sola lettura.

-l è per i symlink, perché dovrebbe fare qualcosa per i hardlink?

(Mi dispiace che questa sia una risposta e non un commento, non ho ancora i diritti di commento e questa risposta aveva bisogno di una risposta)

Un'altra nota che dovrebbe essere un commento: è tutto hardware nativo o sei su una VM, montati in rete?

modificare

ignora il mio precedente commento sul motivo per cui stai usando hardlink, ho perso il rsnapshotcommento.

Sarebbe utile avere un test che test prima rsync tra il disco locale di due directory locali, quindi sul disco remoto. Questo piccolo test mostra l' -Hopzione wokrs come previsto. L' -iopzione per lsmostra gli inode, mostrando così che i collegamenti sono stati conservati, senza copie extra.

$ 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

Un test successivo rsync -avzHP src/ host:/tmpper un host remoto ha comunque mantenuto i collegamenti

Questa è una possibilità, ma se non riesci a trovare un'altra soluzione, suggerirei di provare a formattare l'unità USB come EXT4. Forse questo potrebbe essere il problema: https://bugzilla.samba.org/show_bug.cgi?id=7670

Dato un numero sufficiente di hard link in una cartella di origine e un volume di destinazione abbastanza piccolo, la copia con rsync --hard-links può fallire. Rsync fallisce esaurendo il numero massimo di hard link sulla destinazione <...> il vero problema non è rsync ma il file system sottostante.

Hai provato ad aggiungere l' -lopzione?

So che la pagina man dice che è inclusa in -ama le pagine man non sono sempre accurate al 100%.