[Rozwiązano] Jak przyspieszyć Rsync przy synchronizacji dużej ilości danych przez LAN?

Cześć,
Mam następujący kłopot z synchronizacją dużych (a przynajmniej średnio-dużych) ilości danych między dwoma serwerami NAS wewnątrz jednej sieci LAN (docelowo jeden z nich będzie podłączony przez VPN i będzie znajdował się w innym miejscu). Mianowicie chodzi o ilości rzędu 6 TiB danych (ok. 100 milionów plików i hardlinków do plików, dane backupu programu Urbackup), próbowałem synchronizacji przez Rsync, ale działa to bardzo wolno, mimo użycia argumentów -W i -H (kopiowanie całych plików, i kopiowanie hardlinków jako hardlinków). Momentami co prawda prędkość jest rzędu 500-700 Mbit/s, ale tylko momentami. Większą część czasu prędkość nie przekracza 5 Mbit/s, mimo podłączenia przez gigabit ethernet. Jak się można domyślić, taka synchronizacja trwa strasznie długo, po tygodniu przekopiowało ledwie 4,5 TiB danych. Czy jest jakieś lepsze narzędzie do synchronizacji danych przez sieć, aby wykorzystać w pełni jej przepustowość ?

Witam,

tutaj będzie kilka problemów . Po
1) - osiągnięcie 500-700 Mbit/s na łączu Gigabitowym - nie jest wcale takim zlym osiągiem , zważywszy na wykorzystanie (obciążenie) takiego łącza nie jednym tylko transferem - ale pewnie i normalną pracą w tle. Dodatkowo - kwestie obciążeń na samej magistrali oraz finalnie kontrolerach dysków (rozumiem że same dyski to są dośc wydajne SSDki ... ? )
2) - te skoki prędkości (średniej) są spowodowane najprawdopodobniej - zmianami wielkości plików. Paradoksalnie - wielka ilość ale małych /mniejszych plików - będzie miałą średnią prędkośc kopiowania o wiele niższą niż małą ilość ale znacznie większych plików . Z reguły najszybciej idzie kopiowanie jednego wielkiego zasobu (albo wręcz zawartości całego dysku - ale metodą klasy dd - albo całej partycji. Możnaby rozważyć tego typu rozwiązania - tyle że wtedy nie będzie to w żaden sposób rsync, ale proste nadpisanie zawartości dysku sektor po sektorze. Można też - o ile jest na to miejsce i wydajność obliczeniowa - najpierw dane pakować dla uzyskania jednego ciągłego voluminu danych - a potem przegrywac już całe archiwum. Ale - j.w. - nie będzie to wtedy w żadnej mierze backup przyrostowy ale pełen backup całości
3) żeby powiedzieć coś sensowniejszego (dokładniejszego) niż powyższe - trzeba by poznać więcej szczegółów dot. tych danych które próbujecie zsynchronizować/skopiowac .

chyba na razie tyle .

A więc chodzi o kopię zapasową backupu danych z mojego komputera. Ponieważ budynek, w którym aktualnie mieszkam nie ma piorunochrona (o czym dowiedziałem się próbując powiesić antenę KF na dachu), uznałem że zgodnie z zasadą 3-2-1 przydałaby się kopia zapasowa kopii zapasowej gdzieś indziej - postawię drugi serwer gdzieś u rodziny, i zrobię VPNa między nimi. Bo jak na razie to trafienie piorunem może mi zniszczyć i kompa, i serwer - jest "single failure point". Ponieważ tam mam łącze 1 Gbit/s światłowodowe, a tu mam szansę wykupić takie samo (na razie mam ADSL, ale jak będzie mi działała transmisja po VPNie to będzie sens wykupić światłowód), to liczę na to że uzyskam wydajność podobną jak po LANie. Wiem że tu mogą być dodatkowe problemy, ale tym się zajmę później Na razie testuję kopiowanie między dwoma serwerami które mam w domu w jednej sieci - jeden stoi na Raspberry Pi, drugi na mini-PCcie (HP Prodesk 600 z podpiętą kartą 5x SATA w miejsce dysku SSD M2). Dyski są magnetyczne - serwerowe HDD - w raspberrowym serwerze jest to 2x 10 TB (jeden jest kopią drugiego, coś jak RAID1, bo dosłowny RAID 1 nie chce działać przez przejściówki SATA-USB), w PCtowym - 2x 20 TB (RAID 1 przez system plików BTRFS). SSD o takiej pojemności to by mnie kosztowały ogromny majątek (nawet HDD refurbished tanie nie były...), a nie jestem jakimś Rockefellerem . Domyślam się właśnie że badziewna prędkość wynika z tego, że większa część danych backupu to są hardlinki do istniejących plików - backupy przyrostowe tak wyglądają, a mam je robione co 48 h, więc przez rok ich się ze 180 nazbierało. Jestem dość początkujący w tematyce serwerowo-backupowej, stąd też pewnie czegoś oczywistego nie wziąłem pod uwagę, ale właśnie szukam jakiegoś sensowniejszego sposobu transmisji chmary małych plików przez LAN (a docelowo - VPN). Chyba że tylko pierwszy Rsync będzie się tak ślamazarzył (ten idzie już z 1,5 tygodnia i końca nie widać...). Co ciekawe wygląda na to, że Rsync między dyskami (tak jest zrobiony dziado-RAID1 w raspberrowym serwerku) działa dużo szybciej, mimo że jeden z dysków jest przez USB 2.0 podpięty (480 Mbit/s).

Przetestuj na innym zestawie danych opcję kompresji danych podczas transferu:


Warto też użyć opcji --delete lub któryś z podwariantów, ja preferuję --delete-before. Jeśli z zestawu danych wykluczasz jakieś pliki, trzeba też użyć opcji --delete-excluded.

Dostępne opcje, według manuala:
https://download.samba.org/pub/rsync/rsync.1

Hmm, z tego co mi się wydaje, to kompresja danych na czas transferu nie pomoże - wąskim gardłem NIE jest LAN, a... no właśnie nie wiem co. Czasami idzie ładnie, 500-700 Mbit/s, a czasem (większość czasu) zwalnia poniżej 5 Mbit/s. Obawiam się że czynnikiem limitującym może być czas dostępu do dysku - to w końcu HDD, pewnie jak szuka małe pliki, to musi co chwilę pozycjonować głowicę (słychać jak dysk burczy co chwilę) i to spowalnia transfer. Ale to tylko mój domysł, może problem tkwi gdzie indziej ?

Uran. napisał:

Obawiam się że czynnikiem limitującym może być czas dostępu do dysku - to w końcu HDD, pewnie jak szuka małe pliki, to musi co chwilę pozycjonować głowicę (słychać jak dysk burczy co chwilę) i to spowalnia transfer. Ale to tylko mój domysł, może problem tkwi gdzie indziej ?

That's a bingo. Szanujący się soft do backupu który od samego początku jest tworzony z myślą obsługi replikacji magazynu nie tworzy setek małych plików a pakuje wszystko w duże paczki, tak by to zasuwało

Hmm, czyli nie da się w żaden sensowny sposób przyspieszyć działania kopiowania dysków ? Wydawało mi się (słowo-klucz - wydawało) że mimo tej samej ilości plików transfer "wewnątrz" serwera działa duuużo szybciej niż przez LAN. No niestety Urbackup tworzy całą masę hard-linków albo symlinków, ale w sumie nie kojarzę lepszego pod tym względem narzędzia do backupu - inna sprawa że Urbackup to pierwszy tego typu program jaki znam. Jak na razie działał całkiem fajnie, problem wyszedł dopiero przy kopiowaniu backupu.

Uran. napisał:

czyli nie da się w żaden sensowny sposób przyspieszyć działania kopiowania dysków

Nie dysków a całej macierzy, tak przyspiesza się stosując większą ilość dysków i np, ssd caching.

>>21412553

Ograniczeń sprzętowych nie przeskoczysz. HDD czy Raspberry Pi to nie jest wydajny sprzęt. Na twoim miejscu podpiąłbym te docelowe dyski do tej maszyny, z której chcesz skopiować dane.

Co do programu do backupów, rsync dokładnie do tego służy, nie używam niczego innego.

Noo myślałem o macierzy dysków pod ZFSem z cachem na SSD, ale na razie to dla mnie za skomplikowane, poza tym i tak dałoby się zrobić jedynie na serwerze na PCcie - raspberrowemu już brakuje miejsca na dyski. Rpi 4B ma 2x USB 3.0 i 2x USB 2.0, tak więc jak na razie na 1 USB 3.0 jest dysk SSD z systemem i bazą danych Urbackup, na 2 USB 3.0 jest dysk HDD "główny" do backupu, a na USB 2.0 jest dysk z backupem backupu. O ile Rsync sprawdza mi się do kopiowania z dysku na dysk wewnątrz serwera, to jednak do kopiowania danych z PCta na serwer jako kopia zapasowa by mi chyba nie podpasował. Główną wadą jest tylko jeden krok do tyłu przy Rsyncu - do ostatniej synchronizacji. Urbackup daje mi pełną historię, jakby screenshoty stanu komputera. Już kilkakrotnie zdarzyło mi się że dzięki Urbackupowi odzyskałem starą wersję jakiegoś pliku, która po czasie okazała się być potrzebna.
Rozumiem że Rpi i HDD to nie jest jakoś specjalnie wydajne połączenie, jednakże ma inne zalety - jest ciche, energooszczędne i w jeszcze dającej się znieść cenie - SSD 20 TB kosztował mnie 1300-coś złotych za sztukę, a SSD 8 TB to ponad 4500 zł. Poza tym moje HDD to seria Exos III, z tego co wiem powinna być jedną z najwydajniejszych wśród HDD.

To w takim razie wychodzi na to, że najszybciej będzie fizycznie wsadzić dwa HDD do jednego serwera i skopiować dd czy jakimś innym narzędziem kopiującym "sektor po sektorze" a nie "plik po pliku", a Rsync zostawić do synchronizacji już wstępnie skopiowanych dysków. No cóż, skoro gdzieś wyszło że gołąb jest szybszy od internetu Link, to w sumie nic dziwnego że bezpośrednia kopia wyjdzie szybciej niż przez Rsync.

Edit: Swoją drogą ciekawe czy istnieje jakieś narzędzie, które "pomagałoby" Rsyncowi, ustawiając mu listę kopiowania plików tak, aby dysk musiał jak najmniej się pozycjonować przy odczycie i zapisie ? Żeby zrobić odczyt i zapis możliwie zbliżony do sekwencyjnego ? Wg internetu odczyt sekwencyjny to ok. 250-280 MB/s na początku dysku i ok. 130-150 MB/s na końcu (bliżej osi talerza, to prędkość liniowa mniejsza), a losowy to ok. 15 MB/s... zaraz zaraz, to znaczy że coś mi spowalnia Rsynca bardziej niż sam dysk ! Ciekawe co w sumie go spowalnia ?

No i niestety nic szybszego niż Rsync do kopiowania "plik po pliku" nie znalazłem. Jako że przepełniał mi się już aktualny dysk 8 TB, skopiowałem go przy pomocy dd na dysk 20 TB (no niestety zostało ext4, ale ładnie ciągnął 250-270 MB/s), rozszerzyłem partycję i wsadziłem na miejsce tego 8 TB. Dysk 8 TB wsadziłem do drugiego serwera (aktualnie nieużywanego, docelowo będącego serwerem "poza domem") i tam kazałem mu się kopiować na inny dysk z BTRFSem przy pomocy Rsync. Idzie ciut szybciej niż po LANie, ale tylko ciut szybciej - drobne pliki to jakieś 5-10 MB/s, duże - do 250 MB/s. Cóż, niech się kopiuje, jak skończy to go zsynchronizuję z aktualnym dyskiem 20 TB w małym serwerze (będzie już mała różnica) i zamienię miejscami.