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.

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"

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

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,

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.

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.

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.

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.

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.