Czy opcja kompresji -z z rsync przyspiesza tworzenie kopii zapasowej

W rsync, -zbędzie kompresji danych podczas transferu plików.

Jeśli dobrze rozumiem, -zskompresuj pliki przed przesłaniem, a następnie rozpakuj je po przesłaniu. Czy czas skrócony podczas transferu z powodu kompresji przeważa czas kompresji i dekompresji?

Czy odpowiedź na pytanie zależy od tego, czy utworzę kopię zapasową na zewnętrznym dysku twardym przez USB (2.0 lub 3.0), czy na serwerze przez SSH przez Internet?

To ogólne pytanie. Czy kompresja i dekompresja w punktach końcowych poprawia efektywną przepustowość łącza?

Skuteczne (postrzegane) pasmo łącza wykonującego kompresję i dekompresję w punktach końcowych jest funkcją:

1. jak szybko można skompresować (szybkość procesora)
2. rzeczywista przepustowość sieci

Funkcja jest opisana za pomocą tego wykresu 3D, z którym możesz skorzystać w konkretnej sytuacji:

Wykres pochodzi z artykułu Compression Tools Compared 2005 autorstwa http://www.linuxjournal.com/ .

Jeśli masz bardzo wolne połączenie (pomyśl GPRS), zdecydowanie chcesz skompresować swoje dane tak bardzo, jak to możliwe, w przeciwnym razie twoje połączenie spowolni.

Jeśli masz bardzo wolny procesor i szybkie połączenie (jak wbudowane urządzenie sieciowe), zwykle nie chcesz kompresować danych, w przeciwnym razie procesor spowolni.

Zależy od stopnia kompresji danych oraz mocy obliczeniowej źródła i miejsca docelowego. Z mojego doświadczenia wynika, że ​​pełna kopia zapasowa dysku zostanie skompresowana do około 30-50% jej oryginalnego rozmiaru, więc może warto spróbować. W przeciwnym razie nie zawracaj sobie głowy kompresją. Warto przetestować stopień kompresji pigz -c <your file> | wc -ci porównać zwracany rozmiar z rozmiarem oryginalnym.

Tak, prędkość połączenia określa, czy przyspiesza. Będzie to narzut tylko dla kopii zapasowej USB, ponieważ nie dyski napompują dane, ale proces, który je zapisuje. Tak więc ta sama maszyna, która czyta i defluje, musi ją również napompować i napisać. Rsync to nadal dwa procesy, ale myślę, że twoja pamięć do przekazywania danych z jednego procesu do drugiego jest wystarczająco szybka, a procesor potrzebuje więcej czasu na kompresowanie go (podczas wczytywania go do tej samej pamięci, która później go przekazuje :).

Kompresja pomaga tylko wtedy, gdy masz nadajnik i odbiornik rsync oraz wolniejszą sieć pomiędzy nimi. 1 Gbit może być już wystarczająco szybki, gdy na przykład masz lokalny NAS, 10 Gbit jest już surową prędkością SATA. Tak więc kompresja jest potrzebna tylko wtedy, gdy masz łączność 100 Mb lub mniej i ma sens tylko wtedy, gdy skompresowane dane są kompresowalne.

Myślę, że rsync może zauważyć, że nie działa na dwóch komputerach, ale na jednej i pomija kompresję, ale nie jestem pewien.

tl; dr Over powolne przesyłanie linków, kompresuj, w przeciwnym razie nie. Poniżej znajduje się test prędkości kompresji, link do narzędzia do konwersji przepustowości i niektóre informacje.

Użycie kompresji rsyncprzyspieszy tylko wtedy, gdy łącze pośrednie jest „wystarczająco wolne”, tj. Jeśli maszyna na jednym końcu jest w stanie wygenerować skompresowany strumień danych wystarczająco szybko, aby nasycić łącze komunikacyjne.

Więc jakie jest najwolniejsze łącze, pod którym powinienem użyć kompresji, aby cokolwiek zyskać?

Poniżej znajduje się bardzo nienaukowy test, który pokaże, jak szybko gzipmożna generować dane i co to oznacza, czy ogólnie należy kompresować masowe transfery sieciowe.

Dane wejściowe zmieni wynik testu znacznie . Używam na komputerze nieskompresowanego (!) Zwykłego pliku, który może reprezentować typ danych, które zwykle przesyłam przez sieć. Używanie /dev/zero(tworzenie nieograniczonej liczby zer) byłoby mylące, ponieważ strumień zer byłby bardzo łatwy do skompresowania, a użycie /dev/randombyłoby wprowadzające w błąd z przeciwnego powodu. Zamiast tego używam pliku tar z mojego $HOME/localkatalogu, który zawiera oprogramowanie, które zainstalowałem w swoim $HOME. Plik sam w sobie jest nieskompresowany, ale zawiera mieszankę plików binarnych, małych skompresowanych plików i plików źródłowych / tekstowych. Chciałbym go skompresować z ustawieniem domyślnym, gzipponieważ zmniejszyłby się o 67% z 64 MiB do 22 MiB.

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

Robię to kilka razy, aby poczuć, jaka może być średnia, i dochodzi do około 7800000 bajtów / s.

Następnie używam kalkulatora przepustowości sieci, aby zobaczyć, w co się to przekształca. W tym konkretnym przypadku zdarza się, że jest to przepustowość łącza przewodowego „100Mb Ethernet”, tylko szybciej niż łącze internetowe „Pobieranie VDSL”, nieco szybciej niż łącze bezprzewodowe „802.11 [a / g]” i gdzieś pomiędzy „Bluetooth v3.0” (wolniej) a „USB 2.0” (szybciej).

Oznacza to, że jeśli używam kompresji na czymś szybszym , kompresja prawdopodobnie spowolni przesyłanie pliku.

rsyncmoże nie używać dokładnie tych samych bibliotek, co gzipdo kompresji, ale powyższe wskazałoby przynajmniej trochę podpowiedź.

rsyncrobi więcej niż kompresja, jak wiadomo, a rzeczywisty wzrost prędkości pochodzi tylko z przesyłania [bitów] plików, które uległy zmianie.

Z mojego własnego doświadczenia rsyncwynika , że używanie kompresji z stało się coraz mniej korzystne w ciągu ostatnich 10 lat, ponieważ przepustowość sieci wzrosła (tam, gdzie jestem).

W przypadku tworzenia przyrostowych kopii zapasowych zdecydowanie zaleciłbym sprawdzenie tej --link-destopcji (nie ma to nic wspólnego z tym, co zostało przeniesione, tylko z tym, jak rzeczy są przechowywane w miejscu docelowym). Ponadto, jeśli robisz to przez SSH, nie używaj kompresji, jeśli twoje połączenie SSH jest już skompresowane, i tylko kompresuj połączenia SSH (tunele itp.), Które są na wolnych łączach, z tych samych powodów jak powyżej.