Najłatwiejszy sposób na szybki transfer plików między serwerami Linux?

16

Muszę przenieść pliki z jednego serwera CentOS na inny. Przeniesie 5 MB plików co 10 minut. Nie potrzebujesz szyfrowania.

Co było łatwego w szybkim przesyłaniu plików?

Czy istnieje coś prostszego niż ftp?

Dzięki!

linux  file-transfer 
— Alex L.
źródło
1
Mam wiarę, że smoła nad netcata zatriumfuje ... heh heh ...: serverfault.com/questions/18125/...
— Evan Anderson
Ponieważ nie potrzebuję szyfrowania, ale potrzebuję szybkości, wolę rsync.
— Alex L
Właśnie dowiedziałem się, że transfery HTTP nie mają dużego obciążenia, więc może mógłbym to po prostu wykorzystać.
— Alex L
Nie edytuj odpowiedzi na swoje pytanie, zamiast tego opublikuj ją jako odpowiedź. Wycofana.
— HopelessN00b
„szybki” patrz także unix.stackexchange.com/questions/48399/…
— rogerdpack

Odpowiedzi:

25

rsync

Używałbym rsync przed użyciem ftp lub tftp.

Więcej opcji i (z mojego doświadczenia) bardziej niezawodny transfer.

— KPWINC
źródło
1
Odkryłem również, że rsync zazwyczaj uzyskuje wyższą przepustowość niż cokolwiek innego (scp, cifs, nfs)
— Ophidian
co z transferami http?
— Alex L
@Ophidian Czy masz na myśli używanie rsync jako demona? W przeciwnym razie, jak może być szybszy niż scp, ponieważ oba używają ssh i istnieje szyfrowanie.
— balki
@balki Tak, demon rsync. Nie jest szczególnie gadatliwy, dobrze podaje dane z dysku na linię i wykonuje tak mało pracy, jak jest to konieczne do wypełnienia żądania (na przykład stosuje różnice do plików tekstowych).
— Ophidian
21

tar przez ssh jest w porządku, ale tar przez TCP przez netcat jest tak niski, jak to tylko możliwe! Jeśli jest to jednorazowa sprawa, daj temu szansę:

Na odbiorniku:

nc -l -p 8989 | tar x

Na nadawcy:

tar cf - /source-path | nc (receiving host ip address) 8989

Jeśli robisz to regularnie, prawdopodobnie użyłbym rsync.

— Evan Anderson
źródło
+1 za netcat, szwajcarski scyzoryk
— chmeee
To samo dotyczy ciebie za nie czytanie Evana. Hahaha! W rzeczywistości nie jest to jednorazowa sprawa. Powiedział, że będzie przesyłać 5 MB plików co 10 minut. Może wysyłanie za pomocą kodu Morse'a byłoby dobrą alternatywą? ;-) (uwaga: prywatny żart Evana i mnie)
— KPWINC
8

Dwie osoby wspominały o tar nad ssh, ale nie powiedziały, jak to zrobić. Dla przypomnienia, podstawową procedurą jest uruchomienie:

tar cf - files... | ssh remotehost 'cd /destination && tar xvf -'

Lub, jeśli chcesz rozpocząć przelewy od strony odbierającej:

ssh remotehost 'cd /source && tar cf - files' | tar xvf -

Zaletą robienia tego w ten sposób w porównaniu z rozwiązaniem Netcat firmy Evan jest to, że wszystko można uruchomić z jednego komputera; nie musisz koordynować dwóch wywołań netcat. Jeśli potrzebujesz, aby działało to automatycznie, możesz skonfigurować klucz ssh, który pozwala nawiązywać połączenia bez hasła, i używać tego klucza do tych połączeń.

ssh ma opcję -C do kompresji strumienia danych, lub możesz użyć wbudowanej funkcji kompresji GNU tar:

tar zcf - files... | ssh remotehost 'cd /destination && tar xzvf -'

Rsync to kolejna opcja, ale jego mocną stroną jest aktualizacja plików, które już istnieją na końcu odbierającym. Odkryłem, że jest wolniejszy niż scp lub tar / ssh podczas używania go do przesyłania plików, które jeszcze nie istnieją na drugim końcu.

— Kenster
źródło
1
+1 Co masz na myśli, że nie wszyscy intuicyjnie wiedzą, jak zrobić tar za pomocą ssh? Dziwne. :)
— chaos
tar sam w sobie nie jest wiarygodny - nie ma sprawdzania integralności, jednak dzięki SSH (TLS) zyskujesz integralność ze względu na zdolność TLS do wykrywania zmian danych w locie. Rsync jest lepszym wyborem i Rsync, ponieważ będzie lepiej sprawdzać integralność bez szyfrowania; OP stwierdził, że szyfrowanie nie jest konieczne.
— Kilo
Jakiego sprawdzania integralności potrzebuje tar? Warstwy TCP i ssh zapewniają niezawodny transport danych. Jeśli twierdzisz, że sama tar może zawierać błędy, musisz traktować rsync w ten sam sposób. W rzeczywistości miałem zawieszone transfery rsync z powodu problemów z protokołem. Nie pamiętam, żeby kiedykolwiek robił to potok Tar / Untar.
— Kenster,
6

Użyję scplub tarponad ssh, uczciwie. Szyfrowanie spowalnia rzeczy, ale łatwość konfiguracji i użytkowania, niezawodność i (subiektywnie, oczywiście) znajomość sprawiają, że jestem gotów podjąć trafienie, chyba że naprawdę potrzebuję takiej prędkości.

Możesz przyspieszyć transfer ssh, mówiąc mu, aby używał szybszego szyfru niż domyślny. Domyślnie jest to zwykle 3desi możesz to zrobić -c des, więc będzie to oczywiście szybsze i -c blowfishjest również przedstawiane jako szybkie, chociaż nie przetestowałem tego dokładnie.

(W czasach SSHv1 często można było to zrobić -c none, ale chyba ktoś uznał, że to złe juju.)

— chaos
źródło
4

Jeśli musisz przejść przez scp / ssh, moje eksperymenty pokazują, że najszybszym domyślnie włączonym szyfrem jest RC4. Podajesz szyfr za pomocą „ -c arcfour ” w komendzie ssh / scp:

do wstępnej kopii:

  • scp -c arcfour -r foo/ desthost:/destdir

do aktualizacji:

  • rsync -e 'ssh -c arcfour' -r foo/ desthost:/destdir
— allaryna
źródło
3

Rsync to dobry sposób, ponieważ jeśli przesyłasz te same pliki więcej niż jeden raz, przyspieszy to kopiowanie, jak pokazano w tym cytacie ze strony podręcznika man. 

   rsync is a program that behaves in much the same way that rcp does, but
   has many more options and uses  the  rsync  remote-update  protocol  to
   greatly  speed  up  file  transfers  when the destination file is being
   updated.
   The rsync remote-update protocol allows rsync to transfer just the dif-
   ferences between two sets of files across the network connection, using
   an efficient  checksum-search  algorithm  described  in  the  technical
   report that accompanies this package.
— thepocketwade
źródło
2

FTP jest dość prosty, ale jeszcze prostszym sposobem może być utworzenie udziału NFS na jednym komputerze i zamontowanie go na drugim. Następnie skopiowanie plików będzie polegało na wykonaniu cp z jednego katalogu do drugiego.

— Swoogan
źródło
w zależności od wymagań. Na przykład nie używałbym NFS w Internecie.
— Kyle Hodgson,
1
Słuszna uwaga. W takim przypadku polecam rsync, ponieważ może wznowić przerwanie, jeśli zostanie przerwane. Również dlatego, że przenosi on różnicę między źródłem a miejscem docelowym.
— Swoogan,
pytanie było bardzo ogólne, lubię soulution napisane przez Swoogan, szczególnie, że autor wspomniał, że potrzebują najprostszego rozwiązania i nie wymagają szyfrowania
— integratorIT
2

Jeśli chcesz prędkości, możesz użyć netcata i tar. Będzie szybszy niż ssh, rsync lub scp w sieci lokalnej, w której szyfrowanie nie stanowi problemu. Google „Netcat tar”.

DestinationServer

nc -l -p 7878 | tar -C /target/dir -xzf -

SourceServer

tar -cz /source/dir | nc DestinationServer 7878

To oczywiście wymaga, aby Netcat został faktycznie zainstalowany. Google „Netcat tar”, aby uzyskać więcej informacji.

— robertmoggach
źródło
1

Wierzę, że już rozwiązałeś problem, ale w przypadku, gdy twój ssh działa na innym porcie (nie na standardowym porcie 22), możesz użyć tego

rsync -avz --rsh = 'ssh -pXXXXX' / local / dir / root@192.168.1.2: / remote / dir

Uwaga: - zastąp XXXXX numerem portu - zastąp 192.16.1.2 poprawnym adresem IP zdalnego serwera

— mangia
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.