Jak szybko skopiować dużą liczbę plików między dwoma serwerami

90

Muszę przenieść ogromną liczbę plików mp3 między dwoma serwisami (Ubuntu). Przez ogromny mam na myśli około miliona plików, które mają średnio 300 KB. Próbowałem, scpale zajęłoby to około tygodnia. (około 500 KB / s) Jeśli przesyłam pojedynczy plik przez HTTP, otrzymuję 9-10 MB / s, ale nie wiem, jak przenieść je wszystkie.

Czy istnieje sposób na szybkie przesłanie ich wszystkich?

nicudotro
źródło
1
Jaką masz sieć między serwerami. Zastosowałem zwrotnicę GB Ethernet między 1 kartą sieciową w każdej maszynie. Bardzo dobrze sobie
poradziłem,
Możesz sprawdzić, dlaczego scp jest tak wolny. Może być wolniejszy niż ftp z powodu szyfrowania, ale nie powinien być o wiele wolniejszy.
Zoredache,
Mam między nimi 100 Mb / s. scp działa wolniej na małych plikach (większość z nich jest mała)
nicudotro

Odpowiedzi:

115

Poleciłbym smołę. Gdy drzewa plików są już podobne, rsync działa bardzo dobrze. Ponieważ jednak rsync wykona wiele przejść analiz dla każdego pliku, a następnie skopiuje zmiany, jest znacznie wolniejszy niż tar dla początkowej kopii. To polecenie prawdopodobnie zrobi to, co chcesz. Skopiuje pliki między komputerami, a także zachowa zarówno uprawnienia, jak i prawa użytkownika / grupy.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Zgodnie z komentarzem Mackintosha poniżej, jest to polecenie, którego można użyć dla rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
Scott Pack
źródło
2
+1 Opcja tar jest znacznie bardziej wydajna w przypadku dużej liczby małych plików, ponieważ zarówno scp, jak i rsync będą miały znacznie więcej podróży w obie strony na plik w sieci.
Sekenre
3
rsync działał dla mnie lepiej niż tar
nicudotro
4
Ponadto, jeśli masz dużo procesora (na obu końcach), ale (przynajmniej) wolne łącze między hostami, warto włączyć kompresję (gzip lub bzip) w poleceniu tar.
Vatine
1
@Jamie: Jeśli używasz ssh-agent, należy go użyć. W przeciwnym razie wystarczy użyć opcji „-i”, aby określić, gdzie znaleźć klucz prywatny. Szczegółowe informacje można znaleźć na stronie podręcznika man.
Scott Pack,
3
@niXar Znak zmiany ~znaczenia jest aktywny tylko wtedy, gdy SSH używa terminala. Nie dzieje się tak w przypadku podania polecenia zdalnego (chyba że podasz -topcję). Twoja obawa jest nieważna.
Gilles
35

Zewnętrzny dysk twardy i dostawa kurierem tego samego dnia.

Adam
źródło
10
Heh heh ... żadna technologia sieciowa nie przewyższa przepustowości wozu kombi załadowanego taśmami o prędkości 90 MPH, co? (snicker) Zakładałem, że był w sieci LAN, ponieważ powiedział, że uzyskuje prędkość 9-10 MB / s przez HTTP.
Evan Anderson
2
Dostaję taką prędkość przez Internet, ale mam szczęście, gdzie mieszkam! Jeśli jest w sieci LAN, to i tak taniej!
Adam
2
Ahh-- nie spojrzałem na twoją lokalizację. Tak, słyszałem, że łączność internetowa w Korei jest dość spektakularna. Utknąłem tutaj w USA, cieszę się, że mogę uzyskać 900KB / s przez sieć ...
Evan Anderson
1
Tak, ale możesz dostać pyszne burrito, czekając na zakończenie pobierania, a są tylko około trzy przyzwoite meksykańskie restauracje nawet w Seulu ...
Adam
17

Użyłbym rsync.

Jeśli masz je wyeksportowane przez HTTP z dostępnymi listami katalogów, możesz użyć argumentu wget i --mirror.

Już widzisz, że HTTP jest szybszy niż SCP, ponieważ SCP szyfruje wszystko (a tym samym wąskie gardło na procesorze). HTTP i rsync będą działać szybciej, ponieważ nie szyfrują.

Oto kilka dokumentów na temat konfigurowania rsync na Ubuntu: https://help.ubuntu.com/community/rsync

Te dokumenty mówią o tunelowaniu rsync przez SSH, ale jeśli przenosisz dane w prywatnej sieci LAN, nie potrzebujesz SSH. (Zakładam, że jesteś w prywatnej sieci LAN. Jeśli uzyskujesz 9-10 MB / s przez Internet, chcę wiedzieć, jakie masz połączenia!)

Oto kilka innych bardzo podstawowych dokumentów, które pozwolą ci skonfigurować względnie niezabezpieczony serwer rsync (bez zależności od SSH): http://transamrit.net/docs/rsync/

Evan Anderson
źródło
Podczas gdy SCP rzeczywiście używa pewnego procesora do szyfrowania danych, nie sądzę, że ma on 100% wykorzystanie procesora, więc procesor nie jest wąskim gardłem. Zbyt często zauważyłem, że SCP jest nieefektywny, jeśli chodzi o szybkie transfery.
Cristian Ciupitu
Biorąc pod uwagę, że widział 300K dla SCP i 9 MB dla HTTP, doszedłem do wniosku, że w grę wchodzi wąskie gardło związane z SCP (zwykle CPU). Jednak z pewnością może to być coś innego. Bez znajomości specyfikacji sprzętowych danych maszyn trudno powiedzieć.
Evan Anderson
1
rsync prawie na pewno użyje ssh do transportu, ponieważ jest to zachowanie domyślne, więc wszelkie koszty spowodowane szyfrowaniem w scp będą również obecne w rsync
Daniel Lawson
3
„Już widzisz, że HTTP jest szybszy niż SCP, ponieważ SCP szyfruje wszystko” → ŹLE. O ile nie ma 10-letnich serwerów, nie jest związany procesorem z tym zadaniem.
niXar
1
@RamazanPOLAT - Masz zbyt długi wiersz polecenia. Określ wybór pliku inaczej, a będzie on działał dobrze. Zazwyczaj można po prostu podać katalog źródłowy bez znaku wieloznacznego na końcu. Możesz także użyć argumentów --includei, --excludeaby uzyskać więcej szczegółów.
Evan Anderson
15

Bez długich dyskusji używaj netcat, sieciowego szwajcarskiego noża. Bez obciążeń protokołu, kopiujesz bezpośrednio do gniazda sieciowego. Przykład

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -
Icapan
źródło
2
Niestety z tego, co zauważyłem, netcat jest bardzo nieefektywny, nawet jeśli nie powinien.
Cristian Ciupitu
Głosuję za tobą, ponieważ to naprawdę, naprawdę okropna rada. Jest jedna poprawna odpowiedź: rsync. Mógłbym wymienić wszystkie powody, dla których jest lepszy, ale nie zmieściłby się na tej stronie, nie mówiąc już o tym małym polu komentarza.
niXar
2
@niXar: Jeśli wszystko, co chcesz zrobić, to pojedynczy transfer plików (nie ma potrzeby dalszej synchronizacji), to naprawdę potrzebujesz tarpipe.
Witiko
2
@niXar netcat jest w porządku, jeśli robisz to w bezpiecznym środowisku, takim jak prywatny vlan i / lub VPN.
Lester Cheung,
Netcat doskonale nadaje się do bezpiecznego środowiska, dopóki nie zostaniesz nieco odwrócony, a cały strumień 1 TB jest zły. Mam taki skomplikowany skrypt z kompresją równoległą, wyjściem postępu (przez pv) i sprawdzaniem integralności przez sha512sum, ale po lekkim odwróceniu cały strumień jest zły, ponieważ nie ma możliwości jego odzyskania. To, czego naprawdę potrzebujemy, to lekki protokół, taki jak torrent strumieniowy dla tych bezpiecznych środowisk, gdy potrzebujemy niskiego obciążenia - coś, co sprawdzi integralność na poziomie porcji (np. 4 MB) i może ponownie wysłać porcję, gdy ktoś zawiedzie. TCP crc nie jest wystarczająco wydajny.
Daniel Santos
8

Z dużą ilością plików, jeśli korzystasz z rsync, spróbowałbym uzyskać wersję 3 lub nowszą na obu końcach . Powodem jest to, że mniejsza wersja wyliczy każdy plik przed rozpoczęciem przesyłania. Nowa funkcja nosi nazwę przyrostowej rekurencji .

Nowy algorytm przyrostowej rekurencji jest teraz używany, gdy rsync rozmawia z inną wersją 3.x. To rozpoczyna przesyłanie szybciej (zanim wszystkie pliki zostaną znalezione) i wymaga znacznie mniej pamięci. Zobacz opcję --recursive na stronie podręcznika, aby zapoznać się z pewnymi ograniczeniami.

Kyle Brandt
źródło
7

rsync, podobnie jak inni już polecili. Jeśli obciążenie procesora związane z szyfrowaniem stanowi wąskie gardło, użyj innego algorytmu mniej obciążającego procesor, takiego jak blowfish. Np. Coś takiego

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

janneb
źródło
+1 za punkt za zmianę szyfru
Daniel Lawson
Procesor nie będzie wąskim gardłem, chyba że masz 10G Ethernet i 10-letni procesor.
niXar
1
tylko komentarz: szyfr „-c arcfour” jest szybszy.
Arman
@niXar: Ale jeśli masz już procesor wykorzystujący zadanie na komputerze, jest to problem.
Izaak,
6

Przenosząc wczoraj 80 TB danych (miliony małych plików), przejście z rsyncna tar okazało się znacznie szybsze , ponieważ przestaliśmy próbować

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

i tarzamiast tego przełączyłem się na ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Ponieważ te serwery są w tej samej sieci LAN, miejsce docelowe jest zamontowane w systemie plików NFS w systemie źródłowym, który wykonuje wypychanie. Nie, atimespraw, by było jeszcze szybciej, postanowiliśmy nie zachowywać plików:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Poniższa grafika przedstawia różnicę dokonanej zmiany z rsync na tar. To był pomysł mojego szefa, a mój kolega wykonał go i napisał świetny artykuł na swoim blogu . Po prostu lubię ładne zdjęcia . :)

rsync_vs_tar

Philip Durbin
źródło
Haker, któremu ufam, mówi mi, że „tar nad tc zamiast nfs może być nawet szybszy”. tj. tar cf - directory | ttcp -t dest_machinez ftp.arl.mil/mike/ttcp.html
Philip Durbin
Pytanie niezwiązane, ale skąd pochodzi ten wykres?
CyberJacob,
4

Podczas kopiowania dużej liczby plików odkryłem, że narzędzia takie jak tar i rsync są bardziej nieefektywne, niż muszą być ze względu na narzut związany z otwieraniem i zamykaniem wielu plików. Napisałem narzędzie open source o nazwie szybki archiwizator, które jest szybsze niż tar dla tych scenariuszy: https://github.com/replicon/fast-archiver ; działa szybciej, wykonując wiele jednoczesnych operacji na plikach.

Oto przykład szybkiego archiwizatora vs. tar na kopii zapasowej ponad dwóch milionów plików; szybkie archiwizowanie zajmuje 27 minut, a tar trwa 1 godzinę 23 minuty.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Aby przesyłać pliki między serwerami, możesz użyć szybkiego archiwizatora z ssh, w następujący sposób:

ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
mfenniak
źródło
3

Używam również metody smołowania poprzez netcat, ale wolę używać socat- dużo więcej mocy, aby zoptymalizować dla twojej sytuacji - na przykład, poprawiając ms. (Także śmiej się, jeśli chcesz, ale socatłatwiej mi zapamiętać argumenty, ponieważ są one spójne). Dla mnie jest to ostatnio bardzo częste, ponieważ przenosiłem rzeczy na nowe serwery:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Aliasy są opcjonalne.

kenorb
źródło
2

Inną alternatywą jest Unison . W tym przypadku może być nieco bardziej wydajny niż Rsync i nieco łatwiej jest skonfigurować odbiornik.

Adam D'Amico
źródło
2

Wygląda na to, że w górnej odpowiedzi może być kilka literówek. To może działać lepiej:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'
retracile
źródło
Odkryłem, że polecenie nie powiodło się, gdy użyłem opcji -f.
user11749,
@ user11749: W tym poleceniu są dwie opcje -f, obie są wymagane. Czy mówisz o przekazaniu -f do ssh, aby przejść do tła?
retracile
2
  • Network File System (NFS), a następnie skopiuj je dowolnie, np. Midnight Commander (mc), Nautilus (z gnome). Użyłem NFS v3 z dobrymi wynikami.
  • Samba (CIFS) , a następnie skopiować pliki z tym, co chcesz, ale nie mam pojęcia, jak skuteczne jest.
  • HTTP z wget --mirrorjak sugerował Evan Anderson lub dowolny inny klient HTTP. Uważaj, aby nie mieć żadnych nieprzyjemnych dowiązań symbolicznych lub mylących plików indeksu. Jeśli wszystko, co masz, to pliki MP3, powinieneś być bezpieczny.
  • rsync . Użyłem go z całkiem dobrymi wynikami, a jedną z jego miłych cech jest to, że możesz przerwać i wznowić transfer później.

Zauważyłem, że inni ludzie zalecają używanie netcat . Na podstawie moich doświadczeń z tym mogę powiedzieć, że jest powolny w porównaniu z innymi rozwiązaniami.

Cristian Ciupitu
źródło
2

Dzięki cudownej odpowiedzi Scott Pack (wcześniej nie wiedziałem, jak to zrobić z ssh), mogę zaoferować to ulepszenie (jeśli bashjest to twoja powłoka). Spowoduje to dodanie kompresji równoległej, wskaźnika postępu i sprawdzenie integralności w łączu sieciowym:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvjest ładnym programem do przeglądania postępu dla twojego potoku i pigzjest równoległym programem gzip, który domyślnie wykorzystuje tyle wątków, ile ma procesor (wierzę, że maksymalnie 8). Można dostosować poziom kompresji, aby lepiej dopasować stosunek CPU do sieci przepustowość i zamieniać go z pxz -9ea pxz -djeśli masz dużo więcej niż przepustowość procesora. Musisz tylko sprawdzić, czy obie sumy są zgodne po zakończeniu.

Ta opcja jest przydatna w przypadku bardzo dużych ilości danych, a także sieci o dużych opóźnieniach, ale nie jest bardzo pomocna, jeśli łącze jest niestabilne i spada. W takich przypadkach rsync jest prawdopodobnie najlepszym wyborem, ponieważ można go wznowić.

Przykładowe dane wyjściowe:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

W przypadku urządzeń blokowych:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Oczywiście, upewnij się, że mają ten sam rozmiar lub limit z count =, skip =, seek = itd.

Kiedy dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefskopiuję systemy plików w ten sposób, często najpierw zeruję większość nieużywanego miejsca, co przyspiesza xfer.

Daniel Santos
źródło
1

Nie sądzę, że będziesz mieć coś lepszego niż scp, chyba że zainstalujesz szybsze karty sieciowe. Jeśli robisz to przez Internet, to nie pomoże.

Poleciłbym użycie rsync . Może nie być szybszy, ale przynajmniej jeśli zawiedzie (lub zamkniesz go, ponieważ trwa to zbyt długo), możesz wznowić od miejsca, w którym przerwałeś następnym razem.

Jeśli możesz podłączyć 2 maszyny bezpośrednio za pomocą gigabitowego Ethernetu, prawdopodobnie będzie to najszybsze.

Brent
źródło
Mam między nimi nieużywane łącze 100
Mb / s
1
Nie zrobisz nic lepszego niż SCP? SCP przepycha wszystkie te dane przez krok szyfrowania. SCP będzie jednym z najwolniejszych sposobów na jego skopiowanie!
Evan Anderson
To prawda, że ​​SCP szyfruje dane, ale szybkość szyfrowania jest o rząd wielkości większa niż połączenie sieciowe, a zatem jest nieistotna.
Brent
1

Przy prędkości 100 Mb / s teoretyczna przepustowość wynosi 12,5 MB / s, więc przy 10 MB / s radzisz sobie całkiem nieźle.

Chciałbym również powtórzyć sugestię wykonania rsync, prawdopodobnie przez ssh. Coś jak:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

Przy prędkości 100 Mb / s procesory powinny być w stanie obsłużyć szyfrowanie / deszyfrowanie bez znaczącego wpływu na szybkość przesyłania danych. A jeśli przerwiesz przepływ danych, powinieneś być w stanie wznowić od miejsca, w którym przerwałeś. Uwaga: z „milionami” plików uruchomienie potrwa chwilę, zanim cokolwiek faktycznie przeniesie.

David Mackintosh
źródło
1

Zetknąłem się z tym wyjątkiem, że przesyłałem dzienniki Oracle.

Oto podział

  • scp

    inefficient and encrypted (encrypted = slower than unencrypted 
    depending on the link and your processor) 
    
  • rsync

    efficient but typically encrypted (though not necessarily)
    
  • FTP / HTTP

    both seem to be efficient, and both are plaintext. 
    

Użyłem FTP z wielkim sukcesem (gdzie wielki sukces odpowiada ~ 700 Mb / s w sieci Gb). Jeśli otrzymujesz 10 MB (co odpowiada 80 Mb / s), prawdopodobnie coś jest nie tak.

Co możesz nam powiedzieć o źródle i miejscu docelowym danych? Czy to pojedynczy dysk na pojedynczy dysk? RAID na USB?

Wiem, że to pytanie ma już odpowiedź, ale jeśli twoja sieć działa tak wolno na kablu krosowym Gb / s, coś absolutnie wymaga naprawy.

Matt Simmons
źródło
1

Nie wspomniałeś, czy te dwa komputery są w tej samej sieci LAN, czy też bezpieczny kanał (tj. Korzystający z SSH) jest obowiązkowy, ale innym narzędziem, którego możesz użyć, jest netcat .

Chciałbym użyć następujących na maszynie odbierającej:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Następnie po stronie wysyłającej:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Ma następujące zalety:

  • Brak obciążenia procesora dla szyfrowania, które ma ssh.
  • gzip -1Zapewnia lekką kompresję bez nasycania CPU więc to sprawia, że dobry kompromis, dając trochę kompresji przy zachowaniu maksymalnej przepustowości. (Prawdopodobnie nie jest to tak korzystne dla danych MP3, ale nie boli.)
  • Jeśli możesz podzielić pliki na grupy, możesz uruchomić równolegle dwie lub więcej rur i naprawdę zapewnić nasycenie przepustowości sieci.

na przykład,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Uwagi:

  • Jakikolwiek sposób przeniesiesz, prawdopodobnie uruchomiłbym rsync lub unison, aby upewnić się, że masz wszystko.
  • Możesz użyć tarzamiast, cpiojeśli wolisz.
  • Nawet jeśli nie kończy się za pomocą ssh, chciałbym zapewnić, że nie używa żadnych samej kompresji oraz rurę przez gzip -1siebie, a nie do uniknięcia nasycenia procesora. (Lub przynajmniej ustaw CompressionLevel na 1.)
Evan
źródło
1

Prosty scp z odpowiednimi opcjami z łatwością osiągnie 9-10 MB / s przez LAN:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Z tymi opcjami jest prawdopodobne, że przepustowość stała się 4x lub 5x szybsza niż brak opcji (domyślnie)


źródło
ale nie dla miliona małych plików. sam próbowałeś swojego rozwiązania?
Sajuuk
1

Jeśli masz serwer ftp po stronie src, możesz użyć ncftpget ze strony ncftp . Działa prefekt z małymi plikami, ponieważ używa tar wewnętrznie.

Jedno porównanie pokazuje to: przenoszenie 1,9 GB małych plików (33926 plików)

  1. Korzystanie z SCP zajmuje 11m59s
  2. Korzystanie z rsync zajmuje 7m10s
  3. Korzystanie z ncftpget zajmuje 1m20s
Ali Nikneshan
źródło
1

Możesz także spróbować użyć polecenia BBCP, aby wykonać przelew. To buforowany równoległy ssh, który naprawdę krzyczy. Zwykle możemy uzyskać 90% + szybkość linii, pod warunkiem, że będziemy mogli zasilać rurę.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Zwykle bardzo się staramy, aby uniknąć konieczności przenoszenia się. Korzystamy z pul ZFS, do których zawsze możemy po prostu „dodać” więcej miejsca na dysku. Ale czasami ... musisz po prostu przenieść rzeczy. Jeśli mamy „żywy” system plików, którego kopiowanie może potrwać kilka godzin (lub dni), nawet gdy przechodzimy do pełnego wybuchu .. wykonujemy procedurę wysyłania dwuetapowego ZFS:

  1. Utwórz migawkę ZFS i przenieś do nowej puli na nowym komputerze. Niech to potrwa tak długo, jak to zajmie.
  2. Zrób drugą migawkę i wyślij ją jako przyrostową. Przyrostowa migawka zawiera tylko (znacznie mniejszy) zestaw zmian od pierwszego, więc przechodzi stosunkowo szybko.
  3. Po zakończeniu tworzenia przyrostowej migawki możesz odwrócić oryginał i przejść do nowej kopii, a „przestoje offline” są ograniczone do minimum.

Wysyłamy również zrzuty ZFS również przez BBCP ... Maksymalizuje to wykorzystanie naszej sieci i minimalizuje czas przesyłania.

BBCP jest dostępny bezpłatnie, możesz google go i jest to prosta kompilacja. Po prostu skopiuj go do swojego / usr / local / bin na komputerach src i docelowych, a będzie to w zasadzie działać.

C. Shamis
źródło
1

Wydaje mi się, że moja odpowiedź jest nieco spóźniona, ale mam dobre doświadczenia z używaniem mc (Midnight Commander) na jednym serwerze do łączenia się przez SFTP z drugim serwerem.

Opcja połączenia przez FTP znajduje się w menu „Lewy” i „Prawy”, wprowadzając następujący adres:

/#ftp:[email protected]/

lub

/#ftp:[email protected]/

Możesz nawigować i wykonywać operacje na plikach prawie jak na lokalnym systemie plików.

Ma wbudowaną opcję kopiowania w tle, ale wolę używać polecenia screen i odłączać się od ekranu podczas kopiowania mc (myślę, że wtedy też działa szybciej).

w-sky
źródło
1

Do @scottpack odpowiedź opcji rSync

Aby wyświetlić postęp przesyłania, użyj opcji „--progess” jako opcji po opcji -avW w poleceniu, jak pokazano poniżej.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

wprowadź opis zdjęcia tutaj

Dinesh Sunny
źródło
1

Oto szybki test porównawczy niektórych technik,

  • Źródłem jest 4-rdzeniowy procesor Intel (R) Xeon (E) E5-1620 @ 3,60 GHz z 250 Mb / s i napędem SATA
  • Miejsce docelowe to 6-rdzeniowy procesor Intel (R) Xeon (E) E-2136 @ 3,30 GHz z przepustowością 1 Gb / s i napędem SSD

Liczba plików: 9632, Całkowity rozmiar: 814 MiB, Średni rozmiar: 84 KiB

  • RSYNC: 1m40,570s
  • KOMPRESJA RSYNC +: 0m 26,519s
  • TAR + NETCAT: 1m58.763s
  • TAR + KOMPRESJA + NETCAT: 0m 28,009s

Komenda tar / netcat była następująca:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
Antares
źródło
0

rsync lub możesz spakować go do tar, aby wszystko było w jednym pliku, a następnie scp. Jeśli brakuje ci miejsca na dysku, możesz przesłać tar bezpośrednio nad ssh podczas jego tworzenia.

Adam Gibbins
źródło
0

Jeśli wysyłasz pliki MP3 i inne skompresowane pliki, niewiele zyskasz na żadnym rozwiązaniu, które próbuje dalej kompresować te pliki. Rozwiązaniem byłoby stworzenie wielu połączeń między dwoma serwerami, a tym samym większy nacisk na przepustowość między dwoma systemami. Po osiągnięciu maksymalnego poziomu nie można wiele zyskać bez ulepszania sprzętu. (Na przykład szybsze karty sieciowe między tymi serwerami.)

Wim ten Brink
źródło
0

Wypróbowałem kilka narzędzi do kopiowania pliku 1 GB Wynik jest poniżej: HTTP najszybszy, z najwolniejszym wget -c nc sekunda w linii scp i kilka razy się nie udało. Nie ma możliwości wznowienia działania rsync używa ssh jako backendu, więc ten sam wynik. Podsumowując, wybrałbym http z wget -bqc i dałbym mu trochę czasu. Mam nadzieję, że to pomaga

Mijo
źródło
czy dajesz wgląd w to, dlaczego http jest najszybszy?
Sajuuk
0

Musiałem skopiować dysk BackupPC na inną maszynę.

Użyłem rsync.

Maszyna miała 256 MB pamięci.

Procedura, którą zastosowałem była następująca:

  • wykonane rsyncbez -H(zajęło 9 godzin)
  • kiedy rsync zakończyło, zsynchronizowałem cpoolkatalog i zacząłem z tym pckatalogiem; Przerwałem transfer.
  • następnie ponownie uruchomiono rsyncz -Hflagą, a wszystkie pliki twarde połączone w pckatalogu zostały poprawnie przeniesione (procedura znalazła wszystkie rzeczywiste pliki w, cpoola następnie połączone z pckatalogiem) (zajęło 3 godziny).

Na koniec mogłem sprawdzić, df -mczy nie wydano żadnej dodatkowej przestrzeni.

W ten sposób omijam problem z pamięcią i rsync. Cały czas mogę zweryfikować wydajność za pomocą top i top, a na koniec przesłałem 165 GB danych.

Zabijaka
źródło