Rsync -avzHP podąża za dowiązaniami stałymi zamiast kopiować je jako dowiązania twarde

Używam rsnapshot do tworzenia godzinnych / dziennych / tygodniowych / miesięcznych kopii zapasowych mojego „roboczego” udziału. Teraz próbuję skopiować cały katalog kopii zapasowej na dysk zewnętrzny za pomocą rsync.

Użyłem tego polecenia / parametrów w sesji ekranowej (tak, rsync-exclude.txt leży w katalogu, z którego uruchamiam polecenie)

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

Całość działa na QNAP TS-439, dysk wewnętrzny to pojedynczy dysk (bez RAID) sformatowany EXT4, dysk zewnętrzny ma format EXT3.

Co się dzieje: Rsync podąża za każdym dowiązaniem twardym i kopiuje rzeczywisty plik zamiast odtwarzać zaktualizowane łącze twarde na dysku zewnętrznym. Nie rozpoznałem tego od razu, więc dysk zewnętrzny został skazony na xxx kopii tych samych plików.

Chcę osiągnąć: Skopiowanie całej struktury pliku wygenerowanej przez rsnapshot na dysk zewnętrzny, utrzymując łącza twarde, aby zaoszczędzić miejsce. Uwaga: niekoniecznie musi to zostać wykonane przy użyciu rsync.

Dziękuję za twoje pomysły i czas. Doceniam twoją pomoc, wielki czas.

Aktualizacja: Dowiedziałem się, że rsnapshot nie używa dowiązań symbolicznych, używa dowiązań twardych, więc teraz używam opcji -H, która powinna zachować strukturę dowiązań twardych według Rsnapshot do wielu miejsc docelowych (lub utrzymać strukturę dowiązań twardych), ale nadal nie będzie działać ... czego tu brakuje?

Aktualizacja 2: Znalazłem tutaj inną opinię / wypowiedź na ten temat: rsync z --hard-links zawiesza Steven Monday sugeruje, aby nie próbować rsyncować struktur dużych plików zawierających dowiązania twarde, ponieważ pochłania dużo pamięci i jest to trudne zadanie dla rsync. Prawdopodobnie lepszym rozwiązaniem byłoby wykonanie .img struktury danych, którą próbuję wykonać kopię zapasową. Co myślisz?

Opcja rsyncpolecenia -H(lub --hard-links) teoretycznie zrobi to, co próbujesz osiągnąć, czyli w skrócie: stworzyć kopię twojego systemu plików, która zachowa sztywną strukturę oryginału. Jak wspomniałem w mojej odpowiedzi na inne podobne pytanie , ta opcja jest skazana na niepowodzenie, gdy źródłowy system plików przekroczy pewien próg złożoności twardego łącza.

Dokładna lokalizacja tego progu może zależeć od twojej pamięci RAM i całkowitej liczby twardych linków (i prawdopodobnie wielu innych rzeczy), ale stwierdziłem, że nie ma sensu próbować precyzyjnie go definiować. Co naprawdę się liczy to, że próg jest aż nazbyt łatwo przekroczyć w rzeczywistych sytuacjach, a ty nie wiesz, że nie przekroczył ją, aż nadejdzie dzień, że próbujesz uruchomić rsync -aHlub cp -aże walki i ostatecznie zawiedzie .

Polecam to: Skopiuj mocno powiązany system plików jako jedną jednostkę, a nie jako pliki. Oznacza to, że skopiuj całą partycję systemu plików jako jeden duży obiekt blob. Dostępnych jest wiele narzędzi, ale najbardziej wszechobecne są dd.

W przypadku zapasowego oprogramowania układowego serwer QNAP NAS powinien również mieć ddwbudowane fdisk. Za pomocą fdiskutwórz partycję na dysku docelowym, która jest co najmniej tak duża jak partycja źródłowa. Następnie użyj przycisku, ddaby utworzyć dokładną kopię partycji źródłowej na nowo utworzonej partycji docelowej.

Podczas ddkopiowania musisz upewnić się, że nic się nie zmienia w źródłowym systemie plików, aby uniknąć uszkodzenia kopii w miejscu docelowym. Jednym ze sposobów jest zrobienie tego umountze źródła przed rozpoczęciem procesu kopiowania; innym sposobem jest zamontowanie źródła w trybie tylko do odczytu.

-l jest dla dowiązań symbolicznych, dlaczego miałoby to robić coś dla dowiązań twardych?

(Przepraszamy, to jest odpowiedź, a nie komentarz, nie mam jeszcze uprawnień do komentowania i ta odpowiedź wymagała odpowiedzi)

Kolejna uwaga, która powinna być komentarzem: czy to cały natywny sprzęt, czy jesteś na maszynie wirtualnej, montowany w sieci?

Edytować

zignoruj ​​mój wcześniejszy komentarz dotyczący tego, dlaczego używasz dowiązań twardych, brakowało mi rsnapshotkomentarza.

Przydałby się test, który najpierw testuje rsync między dyskiem lokalnym dwóch katalogów lokalnych, a następnie na dysku zdalnym. Ten mały test pokazuje -Hopcjonalne wokry zgodnie z oczekiwaniami. -iRozwiązaniem dla lspokazów iwęzłówm, pokazując w ten sposób, że linki zostały zachowane, bez żadnych dodatkowych kopii.

$ 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

Kolejny test rsync -avzHP src/ host:/tmpna zdalnym hoście nadal utrzymywał twarde linki

To długa szansa, ale jeśli nie możesz znaleźć innego rozwiązania, proponuję spróbować sformatować dysk USB jako EXT4. Może to może być problem: https://bugzilla.samba.org/show_bug.cgi?id=7670

Biorąc pod uwagę wystarczającą liczbę twardych linków w folderze źródłowym i wystarczająco mały wolumin docelowy, kopiowanie za pomocą rsync --hard-links może się nie powieść. Rsync kończy się niepowodzeniem przez wyczerpanie maksymalnej liczby twardych dowiązań w docelowym <...> prawdziwym problemem nie jest rsync, ale zamiast tego bazowy system plików.

Czy próbowałeś dodać -lopcję?

Wiem, że strona podręcznika mówi , że jest zawarta, -aale strony podręcznika nie zawsze są w 100% dokładne.