Najlepszy sposób przesyłania plików przez sieć LAN między dwoma komputerami z systemem Linux

77

Chcę przenieść pliki (folder muzyczny) między dwoma komputerami z systemem Linux. Po znalezieniu najlepszego sposobu, aby to zrobić, zauważyłem, że istnieje wiele sposobów na zrobienie tego. Wiem, że często o to pytano , wszędzie i przez cały czas . Główny problem polega na tym, że nie ma jasnego, niedawnego konsensusu co do jednego najlepszego sposobu wykonania tego zadania w 2011 roku dla początkujących Linuksa (nawet w zależności od niektórych parametrów).

Tak więc, zgodnie z duchem stron Stack Exchange, nie chcę, aby było to związane z moją szczególną sytuacją, ale raczej jako przewodnik dla innych na temat przesyłania plików między dwoma komputerami z systemem Linux przez sieć lokalną. Myślę, że wiki byłoby przydatne dla wielu.

Oto, co znalazłem do tej pory:

  • ssh
  • sshfs
  • scp
  • sftp
  • nfs
  • samba
  • dawca

Co jest najłatwiejsze? Najbardziej elastyczny? Najprostszy? Najlepsze rozwiązanie? Jakie są zalety i wady każdego z nich? Czy są inne (lepsze) opcje? Jakie są parametry przy wyborze najlepszej metody (rozwiązanie może zależeć od liczby plików, rozmiaru pliku, łatwości kontra elastyczność, ...)?

jonallard
źródło
2
Czy ktoś mógłby wyjaśnić, skąd bierze się rsync w tym wszystkim?
Konerak,
jonallard, nie dodawaj odpowiedzi do pytania (tak naprawdę nie ma sensu tego robić, prawda?) - jeśli uważasz, że niektóre odpowiedzi wymagają dodatkowych informacji, możesz zasugerować ich edycję lub stworzyć własną odpowiedź który podsumowuje wszystko!
slhck,

Odpowiedzi:

65

W środowisku Linux, dla bezpieczeństwa i łatwości użytkowania, ssh jest najlepszym sposobem. SSH, SSHFS, SCP i SFTP na liście to po prostu różne usługi zbudowane na protokole SSH. SCP jest bardzo łatwy w użyciu, działa podobnie jak CP, ale możesz podać nazwy użytkowników i komputerów na ścieżce. Możemy więc wykonać CP cp ~/music/ ~/newmusic/, ale równie łatwo możemy scp ~/music/ user@host:~/newmusicwysłać go do komputera o nazwie host. To wszystko - nie musimy niczego konfigurować. Zostaniesz poproszony o podanie hasła do konta na innym komputerze, jeśli nie masz certyfikatu lub innej konfiguracji uwierzytelnienia (scp oczywiście udostępnia te ustawienia ssh).

SFTP to narzędzie, które ułatwia wykonywanie wielu operacji na zdalnym systemie plików - działa podobnie jak FTP, ale działa przez SSH, więc jest bezpieczny i wymaga tylko serwera SSH. man sftppowie Ci wszystko o tym, jak z niego korzystać. Nie używam SFTP tylko do przenoszenia folderu między dwoma komputerami, jest to bardziej przydatne, gdy masz wiele operacji do zrobienia, na przykład, jeśli porządkujesz pliki na innym komputerze.

SSHFS po prostu rozszerza SFTP na system plików: pozwala na podłączenie wirtualnego hosta do twojego systemu plików, dzięki czemu praca w sieci odbywa się całkowicie transparentnie. SSHFS służy do konfiguracji półtrwałych, a nie tylko jednorazowego transferu plików. Konfiguracja wymaga więcej wysiłku, o czym można przeczytać na stronie projektu .

Jeśli musisz pracować w środowisku z różnymi systemami operacyjnymi, Samba staje się Twoim następnym najlepszym wyborem. Systemy Windows i OS X obsługują Sambę całkowicie automatycznie, podobnie jak Linux, chociaż czasem jest trudny w użyciu.

jcrawfordor
źródło
3
Dokładnie taka odpowiedź, jakiej pragnąłem: kompletna, wyczerpująca, szczegółowa, do rzeczy.
jonallard
2
Jedną rzeczą jest jednak to, że scpaby działać, musimy skonfigurować jakiś serwer ssh, odbiornik lub odblokować coś po drugiej stronie? Otrzymuję błędy „Odmowa połączenia”.
jonallard
2
scp używa ssh, więc będzie działać, jeśli działa SSH. Oznacza to oczywiście, że musisz mieć uruchomiony serwer SSH (domyślnie w każdej dystrybucji Linuksa, o której wiem) i połączenie musi być możliwe (zapory ogniowe, NAT itp. Muszą mieć odpowiednie wyjątki).
jcrawfordor
8
Najwyraźniej openssh-servermusi być zainstalowany w Ubuntu Natty.
jonallard
3
Pamiętaj, że sshużywa szyfrowania, co spowoduje dodatkowe obciążenie. Jeśli zaangażowane komputery mają dość powolne procesory, może to mieć znaczenie. W takim przypadku netcatpreferowane może być coś podobnego (patrz odpowiedź Caspara). Oczywiście tylko wtedy, gdy tak naprawdę nie potrzebujesz szyfrowania (w chronionej sieci LAN).
śleske,
59

Moim osobistym faworytem w przypadkach, w których bezpieczeństwo nie ma znaczenia, jest netcat + tar :

Aby wysłać katalog, przejdź do katalogu, którego zawartość chcesz wysłać na komputer wykonujący wysyłanie, i wykonaj:

tar -cz . | nc -q 10 -l -p 45454

Na komputerze odbierającym zawartość przejdź do miejsca, w którym chcesz ją wyświetlić, i wykonaj następujące czynności:

nc -w 10 $REMOTE_HOST 45454 | tar -xz

Zamień na $REMOTE_HOSTip / nazwa hosta komputera wykonującego wysyłanie. Możesz również użyć innego portu zamiast 45454.

W rzeczywistości dzieje się tak, że komputer „odbierający” łączy się z komputerem wysyłającym na porcie 45454 i odbiera zawartość katalogu tar i gzip i przekazuje ją bezpośrednio do tar (i gzip), aby wyodrębnić go do bieżący katalog.

Szybki przykład (użycie hosta lokalnego jako hosta zdalnego)

Komputer 1

caspar@jumpy:~/nctest/a/mydir$ ls
file_a.txt  file_b.log
caspar@jumpy:~/nctest/a/mydir$ tar -cz . | nc -q 10 -l -p 45454

Komputer 2

caspar@jumpy:~/nctest/b$ ls
caspar@jumpy:~/nctest/b$ nc -w 10 localhost 45454 | tar -xz
caspar@jumpy:~/nctest/b$ ls
file_a.txt  file_b.log
Caspar
źródło
poniekąd przypomina mi sendnet i recnet z nowatorskich usług ipx z dawnych czasów ...
sum1stolemyname 22.08.11
4
## netcat + bzip2 może być trochę szybszy na wolnych połączeniach ## Serwer wysyłający # cat file.txt | bzip2 -c | nc -l 1234 ## Serwer odbierający # nc $ send_ip 1234 | bzip2 -cd> file.txt
shantanuo
@Caspar: Co powiesz na edycję tej odpowiedzi, aby zasugerować kompresję bzip2 lub lzma?
einpoklum
4
-qopcja wskazuje, że używasz OpenBSD-netcat , natomiast gnu-netcat jest również dość powszechne (domyślnie w Arch Linux ). Czy możesz rozszerzyć swoją odpowiedź o składnię gnu-netcat ?
Sebastian
1
Obecny nc man mówi o opcji -l: „Błędem jest używanie tej opcji w połączeniu z opcjami -p, -s lub -z”, ale o dziwo nie rzuca błędu podczas jej używania. Myślę, że użycie 'nc -l 45454' powinno równie dobrze działać.
Claudiu
19

Dla jednego ruchu zaleca się scp.

Ale jeśli okaże się, że ten katalog może działać i musisz wiele razy go przenosić, aby zachować aktualną pozycję, możesz użyć rsync (z ssh).

Ponieważ rsync ma wiele argumentów, zwykle umieszczam go w małej powłoce, więc mam rację (za każdym razem). Chodzi o to, aby wysyłać tylko rzeczy, które zmieniły się od ostatniego uruchomienia.

#!/bin/bash

user="nisse"
host="192.168.0.33"

echo "Sync: /home/media/music/"
rsync --archive --delete -v --progress -e "ssh -l $user " /home/media/music/ $host:/home/media/music/

Spowoduje to przeniesienie katalogu o nazwie „/ home / media / music /” z komputera lokalnego na komputer o nazwie 192.168.0.33, za pomocą użytkownika „nisse”. I usuń wszystko z celu, który nie istnieje na lokalnym komputerze.

Johan
źródło
1
+ dla rsync, który wydaje się odrobinę szybszy i jest bardzo fajny, jeśli musisz później zsynchronizować katalog
Wiesław Herr
Wydaje się to bardzo obiecujące (i łatwe do ponownego użycia), ale mam katalogi i pliki ze spacjami i otrzymuję błąd rsync: błąd składni lub użycia (kod 1) na main.c (1348) [sender = 3.1.1] - - jakieś sugestie?
Torben Gundtofte-Bruun
8

Polecam wypróbować alternatywne rozwiązania zamiast iść prosto z SSH do przenoszenia plików wewnątrz własnej sieci LAN, ponieważ narzut jest NIESAMOWITY. Wybrałbym rozwiązanie Caspara, jeśli to z jakiegokolwiek powodu nie zadziała dla ciebie:

U źródła:

$ python3 -m http.server {PICK_YOUR_PORT}

Na miejscu:

$ wget -r {ip / hostname}:{port}/{File / Directory}

Jest to nie tylko lżejsze niż przy użyciu SSH, ale znacznie szybsze przy prędkościach w zakresie 45 ~ 65 Mb na standardowym UTP CAT6.
Jeśli naprawdę chcesz wycisnąć jak najwięcej z połączenia, spróbuj zastąpić wgetje lftpza pomocą poleceń pget -n20i mirror -r.

cig0
źródło
7

Prawdopodobnie najszybszy netcat(jak opisano Caspar).

Podoba mi się połączenie tar& ssh, które jest bezpieczne i wciąż szybkie:

W źródle

tar -cf - . | ( ssh user@target && cd /target/path && tar -xf - )

Robiąc to jako root, zachowuje uprawnienia do plików. Lub użyj -ppo obu stronach. Można również -Swziąć pod uwagę, jeśli masz rzadkie pliki.

Możliwe jest zmniejszenie obciążenia związanego z szyfrowaniem, sshjeśli używasz arcfourjako szyfru, który działa z openSSH:

tar -cpSf - . | ( ssh -c arcfour user@targethost && cd /target/path && tar -xpSf - )

Aby zaktualizować zdalną ścieżkę, rsyncidealnie:

rsync -av --sparse --delete -e "ssh -c arcfour" . root@targethost:/target/path
Tim Haegele
źródło
1
FWIW, ostatnio przeprowadziłem test transferu między dwoma bezpośrednio podłączonymi nowoczesnymi laptopami, używając rsync, zarówno z opcją arcfour, jak i bez konkretnego argumentu -e. Nie zauważyłem różnicy prędkości.
Randy Syring
4

Jeśli absolutnie trzeba to zrobić za pośrednictwem sieci LAN, skorzystam rsync, ponieważ w razie przerwania podejmie przerwę. Ma też kilka innych sztuczek, aby zminimalizować ilość przesyłanych danych, chociaż wątpię, aby wiele / którekolwiek z nich byłyby odpowiednie w przypadku kopiowania biblioteki muzycznej do dziewiczej lokalizacji. Jeśli bezpieczeństwo stanowi problem, po prostu ustaw RSYNC_RSH=sshnajpierw, a dane będą tunelowane przez ssh.

Gdybym jednak to robił, prawdopodobnie w ogóle nie używałbym sieci LAN. Skopiowałem pliki na dysk twardy USB, a następnie z niego. Z mojego doświadczenia wynika, że ​​może to być o wiele rzędów wielkości szybsze niż przejście przez sieć LAN, pomimo konieczności dwukrotnego kopiowania plików - USB 2.0 jest oceniany na 480 Mb / s, co jest szybsze niż cokolwiek innego niż gigabit Ethernet, a ponadto jest mniej wrażliwy na warunki co obniży wydajność sieci LAN. Jest również całkowicie niezależny od systemu operacyjnego, pod warunkiem, że używasz systemu plików, który mogą obsługiwać wszystkie zaangażowane maszyny - polecam VFAT / FAT32, ponieważ jest to dość uniwersalne.

Dave Sherohman
źródło
1
Jestem także fanem (tak zwanego) sneakernet, ale warto zauważyć, że chociaż USB 2 ma być w stanie uzyskać 480 Mb / s, widziałem tylko, że osiąga prędkość 30 MB / s (około 240 Mb / s). , może po prostu mam tani sprzęt USB <-> SATA;) Ponadto FAT32 jest dość uniwersalny, ale nie można go kopiować np. obrazów DVD ze względu na ograniczenie wielkości plików 4 GB; warto zwrócić uwagę, aby ludzie nie frustrowali się komunikatem o błędzie „brak miejsca”, który Windows (przynajmniej) daje.
Caspar
@Caspar: Dobre zastrzeżenia! Dzięki za ich wzmiankę; Zawsze zapominam o limicie rozmiaru pliku FAT32 ...
Dave Sherohman,
2

Sugerowałbym rsync, ponieważ będzie on stopniowo kopiował pliki. Możesz skonfigurować kopiowanie tylko zmodyfikowanych lub nowych plików tylko po wykonaniu pierwszej aktualizacji. Możesz użyć ssh jako warstwy transportowej, jeśli chcesz.

Sardathrion
źródło
1

Używam Unison , który jest niesamowitym synchronizatorem plików w wielu różnych protokołach. Można skonfigurować go do używania scp, rcp, ftpa nawet lokalnie w systemie plików pomiędzy dwoma folderami. Używam go do synchronizowania biblioteki muzycznej, ponieważ może przesyłać wiele plików jednocześnie przez sieć i jest naprawdę dostrajany w konfiguracji. Kopię zapasową mojej kolekcji muzycznej i synchronizuję na 2-3 komputerach. Kopiuje tylko zmienione pliki i robi to, utrzymując indeks na obu końcach przesyłania, aby móc stwierdzić, kiedy klient zmienił plik lub kiedy plik serwera się zmienił.

Twój przebieg może się różnić, ale z pewnością jest o wiele lepszy niż scpgromadzenie całej kolekcji muzycznej za każdym razem, gdy dodajesz nową piosenkę :)

Naftuli Kay
źródło
0

Najpierw postępowałem zgodnie z procesem ssh dla logowania bez hasła http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/

W przypadku skryptów i plików tekstowych następujące działanie jest dla mnie w porządku

Aby przenieść dane z hosta lokalnego do hosta zdalnego. cat localfile | ssh <user>@<ip> "cat > <path>/<remotefile>"

Aby przenieść dane z hosta zdalnego do hosta lokalnego. ssh <user>@<ip> "cat > <path>/<remotefile>" | cat > localfile

Działa to dla mnie, aby przesyłać pliki w systemach osadzonych, które nie mają wbudowanego klienta ssh lub scp.

Bez scp - tylko ssh.

entuzjastyczny
źródło