Najszybszy sposób na przeniesienie 55 GB zdjęć na nowy serwer

64

Obecnie mam dwa serwery CentOS. Muszę wiedzieć, w jaki sposób i jaki byłby najszybszy sposób na „zszorowanie” katalogu obrazów i przeskanowanie go?

Czy to najszybszy sposób, który właśnie zasugerowałem, ponieważ tarowanie trwa wiecznie ... Uruchomiłem polecenie:

tar cvf imagesbackup.tar images

I zamierzałem to po prostu przeskanować.

Daj mi znać, jeśli istnieje szybszy sposób. Mam dostęp zdalny / SSH do obu komputerów.

Andrew Fashion
źródło
12
Sneakernet?
Nick T

Odpowiedzi:

98

Zamiast używać tar do zapisu na dysku lokalnym, możesz pisać bezpośrednio na zdalnym serwerze przez sieć za pomocą ssh.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Każdy ciąg następujący po komendzie „ssh” będzie uruchamiany na zdalnym serwerze zamiast logowania interaktywnego. Możesz przesyłać dane wejściowe / wyjściowe do i ze zdalnych poleceń przez SSH, tak jakby były lokalne. Umieszczanie polecenia w cudzysłowach pozwala uniknąć nieporozumień, szczególnie podczas korzystania z przekierowania.

Lub możesz wyodrębnić plik tar na innym serwerze bezpośrednio:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Zwróć uwagę na rzadko używaną -Copcję. Oznacza to „najpierw zmień ten katalog, zanim cokolwiek zrobisz”.

A może chcesz „wyciągnąć” z serwera docelowego:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Zauważ, że <(cmd) konstrukcja jest nowa do bash i nie działa na starszych systemach. Uruchamia program i wysyła dane wyjściowe do potoku i zastępuje potok w poleceniu, tak jakby był plikiem.

Mogłem łatwo napisać powyższe w następujący sposób:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Lub w następujący sposób:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Możesz też zaoszczędzić trochę smutku i po prostu użyć rsync:

server1$ rsync -az ./path server2:/destination/

Na koniec pamiętaj, że kompresja danych przed przesłaniem zmniejszy przepustowość, ale w przypadku bardzo szybkiego połączenia może to spowodować, że operacja zajmie więcej czasu . Wynika to z faktu, że komputer może nie być w stanie skompresować wystarczająco szybko, aby nadążyć: jeśli kompresja 100 MB zajmuje więcej czasu niż wysłanie 100 MB, wówczas szybsze jest przesłanie jej bez kompresji.

Alternatywnie, możesz rozważyć użycie pipingu do samodzielnego gzipowania (zamiast korzystania z opcji -z), abyś mógł określić poziom kompresji. Z mojego doświadczenia wynika, że ​​w przypadku szybkich połączeń sieciowych z kompresyjnymi danymi używanie gzip na poziomie 2 lub 3 (domyślnie jest to 6) daje najlepszą ogólną przepustowość w większości przypadków. Tak jak:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
tylerl
źródło
Rsync działał pięknie - kompresuje w locie, kopiuje całe foldery, wznawia po zerwaniu linku. Wszystko w jednym prostym poleceniu. Kocham to. Są to opcje, które uważam za przydatne: z: kompresja r: recurse = kopiowanie podfolderu v: pełne. Mój przykład polecenia Rsync: rsync -azvr / src-path / username @ dest_server: / dest / path /
Bastion
68

Kusiłoby mnie, aby zsynchronizować to nad sobą - dobrze kompresuje i dobrze radzi sobie z utratą linków.

Siekacz 3
źródło
14
rsync jest dokładnie właściwym narzędziem.
Rich
4
+1 - Yay rsync!
Evan Anderson,
1
+1, po prostu nakładać. Poza tym naprawdę lubię rsync.
Steven poniedziałek
1
Ale podczas korzystania z rsync i tak będziesz musiał ręcznie skompresować dane (jeśli chcesz zapisać skompresowane dane)
wlk
Jak przechowywać skompresowane pliki za pomocą rsync?
Dolan Antenucci,
12

Jeśli po prostu je zmobilizujesz, nic więcej nie zmarnuje czasu przy minimalnym przyspieszeniu.

Tak więc po prostu tarowanie plików za pomocą przełączników cvf będzie skutecznie kosztować czas potrzebny do odczytania wszystkich 55 GB zdjęć i zapisania ich z powrotem na dysk. (W efekcie będzie to jeszcze więcej czasu straconego, ponieważ będzie znaczny koszt ogólny).

Tutaj zyskujesz tylko jedną zaletę: zmniejsza się obciążenie związane z przesyłaniem wielu plików. Możesz skrócić czas przesyłania, jeśli skompresujesz obrazy (ale ponieważ uważam, że są one już w skompresowanym formacie, nie będzie to zbyt pomocne). Po prostu więcej straty czasu na komputerze.

Największą wadą przesyłania ogromnego archiwum tar przez drut jest to, że jeśli coś pójdzie nie tak, może to oznaczać, że musisz zacząć od nowa.

Użyłbym w ten sposób:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

Na nowym serwerze

md5sum /images/* > md5sum_new.txt

A potem tylko diff. A ponieważ scp obsługuje kompresję w locie, nie ma potrzeby tworzenia osobnych archiwów.

Edytować

Zatrzymam informacje MD5, ponieważ były przydatne dla PO. Ale jeden komentarz uderzył mnie nowym spojrzeniem. Trochę poszukiwań dostarczyło tej użytecznej informacji. Należy pamiętać, że przedmiotem tutaj jest SFTP, a nie bezpośrednio SCP .

W przeciwieństwie do FTP, SFTP zwiększa obciążenie transferu plików. Podczas przesyłania pliku między klientem a serwerem jest on dzielony na mniejsze części zwane „pakietami”. Załóżmy na przykład, że każdy pakiet ma rozmiar 32 KB. Protokół SFTP wykonuje sumę kontrolną dla każdego przesyłanego pliku 32 KB i obejmuje tę sumę kontrolną wraz z tym pakietem. Odbiorca pobiera ten pakiet i odszyfrowuje dane, a następnie weryfikuje sumę kontrolną. Sama suma kontrolna jest „silniejsza” niż suma kontrolna CRC32. (Ponieważ SFTP używa 128-bitowej lub wyższej sumy kontrolnej, takiej jak MD5 lub SHA, i ponieważ odbywa się to na każdym pakiecie, istnieje bardzo szczegółowa kontrola integralności, która jest przeprowadzana jako część transferu.) Zatem protokół sam jest wolniejszy (z powodu dodatkowego obciążenia), ale pomyślne zakończenie transferu oznacza de facto,

pacey
źródło
Dziękuję bardzo, co robi md5sum? a czym jest diff? Dziękuję, występuję teraz!
Andrew Fashion,
2
md5sum (lub md5) pobiera sumę kontrolną plików. Diff szuka różnic w plikach (man diff). Suma kontrolna tworzy ciąg, skrót, że jeśli plik zostanie zmieniony w trakcie przesyłania ... nieco odwrócony, błąd ... nie będzie pasował, gdy weźmiesz go ponownie po drugiej stronie. W przypadku dużych plików masz zwiększoną szansę na błędy. Dlatego gdy widzisz witryny, które umożliwiają pobieranie plików .iso, często mają sumę kontrolną MD5, w której możesz porównać pobrany plik, aby upewnić się, że pasuje i nie jest uszkodzony.
Bart Silverstrim,
3
scp jest szyfrowany i gwarantuje integralność przez linię. Nadal istnieje niewielka szansa, że ​​dane zostały uszkodzone w pamięci lub na dysku, ale jest to dość rzadkie.
Ryan Bair,
1
Czy narzut sum kontrolnych SFTP ma znaczenie w praktyce? Nie mogę sobie tego wyobrazić. 4 bajty na każde 32768 nie wydają się znaczące. To 128 kB na GB. Nazywanie tego „wolniejszym” wydaje się przesadą w czymkolwiek innym niż nudny sens teoretyczny.
underscore_d
8

Oprócz sugestii md5sum Pacey'a użyłbym następujących:

W miejscu docelowym: nc -w5 -l -p 4567 | tar -xvf -

Następnie w źródle: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Nadal jest to tar / untar i nie ma szyfrowania, ale jest bezpośrednio skierowane na inny serwer. Rozpocznij je oba w tandemie ( -w5daje 5 sekund łaski). Jeśli przepustowość jest wąska, dodaj -z do tar na obu końcach.

SmallClanger
źródło
1
Myślę, że jest odwrotnie, najpierw musi wykonać na miejscu docelowym (aby otworzyć gniazdo), a następnie na źródle (wysłać)
Dimitrios Mistriotis,
zamiast serwera docelowego, czy mogę po prostu wpisać [email protected]?
Andrew Fashion,
Nie, tylko adres IP. netcat nie używa protokołu innego niż TCP :) To polecenie będzie również najszybszym ze wszystkich poleceń podanych powyżej. W źródle znajduje się dokładnie jeden odczyt, dokładny minimalny ruch sieciowy do przesłania plików i dokładnie jeden zapis na plik w miejscu docelowym. Jeśli masz wolne cykle procesora, dodanie flagi -z (dla kompresji) przyspieszy ją, ponieważ trzeba przesłać mniej danych sieciowych.
Jeff McJunkin,
@ user36845 - Prawda. Nie sugerowałem się chronologią w powyższej kolejności, ale masz rację, gniazdo trzeba najpierw otworzyć. Zmienię to, aby wyjaśnić. :)
SmallClanger
Nie jestem pewien, dlaczego ssh / scp ograniczały prędkość od 125 MB / s do 133 MB / s, ale netcat może łatwo przesyłać dane z prędkością ~ 380 MB / s (ten sam link)
ThorSummoner
1

Jeden punkt - nie wszystkie hosty mają rsync i może hosty mogą mieć różne wersje tar. Z tego powodu można polecić jako pierwszy port wywoławczy, używając często zaniedbywanego cpio.

Możesz cpio przez ssh, aby wykonać replikację ad-hoc struktur plików / katalogów między hostami. W ten sposób masz lepszą kontrolę nad tym, co jest wysyłane, ponieważ musisz „nakarmić” CPIO, NOM-NOM. Jest również bardziej przenośny na argumenty, cpio niewiele się zmienia - jest to ważny punkt, jeśli dbasz o wiele hostów w heterogenicznym środowisku.

Przykład kopiowania / eksportu / home i podkatalogów do zdalnego hosta:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Powyższe spowoduje skopiowanie zawartości katalogu / export / home i wszelkich podkatalogów do katalogu / export / home na zdalnym hoście.

Mam nadzieję że to pomoże.

Rowley
źródło
Wspomniał, że były to dwa urządzenia CentOS, więc będą miały wersje rsync i kompatybilne z plikami tar. Narzędzia takie jak rsync zostały utworzone w celu zastąpienia narzędzi takich jak cpio :). Nie możesz „wznowić” z cpio, przynajmniej nie wiedząc od czego dokładnie zacząć i odpowiednio odfiltruj znalezisko. Co jest niepotrzebnym narzutem czasu. Powiedziawszy to, przydatne informacje o „starych” pudełkach UNIX :)
Rafiq Maniar
Tak, ten cmmand stracił mnie haha
Andrew Fashion
1

Mam dostęp ssh, masz dostęp rsync.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

lub

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Jeśli pojawi się błąd typu „błąd rsync: niektórych plików nie można przenieść (kod 23) na main.c (977) [nadawca = 2.6.9]”, sprawdź użytkownika i grupy między serwerami; możesz mieć niedopasowanie.

Użyj opcji rsync „-z”, jeśli chcesz, aby rsync skompresował transfer. Ta opcja zużywa więcej procesora, ale mniejszą przepustowość, więc pamiętaj o tym.

Istnieje opcja „--progress”, która da ci procent przeniesiony, co jest miłe, jeśli lubisz tego rodzaju rzeczy.

quinnr
źródło
0

Czy znajdują się we wspólnej sieci, a nie potrzebują internetu do przesyłania plików? NFS lub FTP mogą być znacznie szybsze niż narzut SCP, chociaż utracisz szyfrowanie podczas przesyłania.

Tex
źródło
różne serwery w zdalnych lokalizacjach
Andrew Fashion,
0

Lub zawsze możesz użyć rur smołowych:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, możesz użyć 'z' dla gzip lub --lzma, jeśli twoja tar go obsługuje.

OneOfOne
źródło