Jak wysyłać ogromne pliki z jednego serwera na inny serwer

Muszę przenieść ogromny plik (ponad 70 GB) z jednego serwera w Kanadzie na inny serwer w Afryce.

Próbowałem FTP, ale zawsze gdzieś się rozłączałem. I wydaje mi się, że sieć nie jest stabilna dla afrykańskiego serwera, część pliku została przesłana, ale kiedy ją otwieram, jest uszkodzona.

Naprawdę potrzebuję narzędzia do przeniesienia dużego pliku:

1. Wykorzystaj przepustowość, aby móc przesłać ją jak najszybciej.
2. Jeśli sieć nie jest stabilna, narzędzie może ją wykryć, upuścić uszkodzone dane i przesłać je ponownie.
3. Nie chcę przesyłać w inne miejsce (jak większość rozwiązań do udostępniania plików, przesyłać na ich serwer i uzyskać jeden link do udostępniania)
4. Wolę narzędzie, które można zainstalować na obu serwerach.

System operacyjny to Windows Server 2008 R2 dla obu serwerów. Nie mogę korzystać z zewnętrznego kanału przesyłania.

BitTorrent może być dla Ciebie dobrym rozwiązaniem.

Utwórz torrent na serwerze źródłowym, przenieś plik torrent do miejsca docelowego, a następnie użyj jednego z klientów jako bittorrent tracker. Bittorrent dzieli plik na łatwe do zarządzania części i zapewnia, że ​​wszystkie zostaną przesłane bezbłędnie.

Oczywiście tworzenie pliku torrent wiąże się z pewnymi narzutami i nie ma roju, który zwiększyłby prędkość pobierania, ale jeśli masz do czynienia z kiepskim linkiem, może on działać bardzo dobrze.

FTP jest okropny - narodził się w połowie lat osiemdziesiątych i, szczerze mówiąc, powinien tam umrzeć.

Prawdopodobnie zacznę od scp (Secure Copy), który powinien być częścią pakietu openssh lub openssh-client na twojej ulubionej dystrybucji Linuksa (w tym Cygwin) lub dostępny jako część pakietu PuTTY, jeśli używasz systemu Windows bez Cygwin . Musisz skonfigurować serwer ssh na docelowym hoście, ale jest to dość proste, zakładając, że masz uprawnienia roota / administratora (jeśli nie, sprawy stają się trudniejsze); kiedy już uruchomisz serwer ssh i możesz uzyskać do niego dostęp z hosta źródłowego, to tylko kwestia

 user@source $ scp /path/to/file user@destination:/path/to/receiving/directory

To powinno dobrze zaspokoić twój punkt 1, ponieważ scp ma dość niski narzut; z pewnością powinien spełniać punkt 2, ponieważ na pewno wykryje nieudane połączenie i może (prawdopodobnie) zostać skonfigurowany lub (na pewno) skrypty, aby spróbować ponownie tyle razy, ile to konieczne; z łatwością obejmuje punkt 3, ponieważ nie jest wymagany pośredni host ani usługa; i ładnie obejmuje również punkt 4, ponieważ możesz zainstalować serwer ssh na obu hostach, a następnie przesłać plik w dowolnym kierunku. Otrzymujesz również szyfrowanie za darmo, co może, ale nie musi być przydatne.

Podręcznik OpenSSH jest prawdopodobnie dobrym miejscem na rozpoczęcie i chętnie udzielę dalszej pomocy, jeśli zdecydujesz się na tę trasę - mam pewne doświadczenie w używaniu scp / ssh do tego rodzaju transferów (chociaż nie z Kanady do Afryki i odwrotnie, i nie dla jednego pliku o rozmiarze 70 GB, przyznaję!)

Mam nadzieję że to pomoże!

Myślę, że dobrym pomysłem byłoby podzielenie pliku na kilka małych, przesłanie ich, a następnie ponowne złożenie na zdalnym serwerze.

Przykład (w systemie Linux) sposobu dzielenia i łączenia jest tutaj: http://www.techiecorner.com/107/how-to-split-large-file-into-several-smaller-files-linux/

Powinieneś także mieć coś w rodzaju połączenia ssh ze zdalnym serwerem, abyś mógł tam je połączyć.

Pomocne byłoby również narzędzie takie jak „md5sum”, aby sprawdzić, czy przesyłane pliki nie uległy zmianie poprzez porównanie skrótów.

Możesz albo napisać mały skrypt powłoki, aby zautomatyzować niektóre rzeczy, abyś mógł bezboleśnie przesyłać wiele małych plików, lub możesz to zrobić ręcznie i wypróbować z kilkoma, ale większymi fragmentami ...

W zależności od prędkości wysyłania i pobierania (zwykle problem stanowi przesyłanie), najlepszym sposobem jest zapisanie go na dysku HD i przesłanie go za pośrednictwem Fedex, DHL lub podobnej usługi, aby ktoś mógł go skopiować na serwer, jeśli to możliwe.

Na przykład, jeśli prędkość wysyłania wynosi 1 Mb / s, prześlesz 1M / 8 = 128 KB / s. Tak więc, nie licząc żadnych „problemów”, takich jak narzut związany z szyfrowaniem (na przykład przy użyciu scp) lub połączenie nie w 100% pełne, plik będzie wymagał 70G / 128K = więcej niż 500.000 s lub 160 godzin (więcej niż 6 dni). Jeśli twoje połączenie nie jest bardzo stabilne, zajmie to (prawdopodobnie dużo) więcej czasu.

Rozważę umieszczenie pliku na zestawie dysków DVD lub BD-ROM lub dysku twardego 2,5 "i wysłanie ich pocztą lotniczą.

Jeśli przepustowość przesyłu wynosi 1 Mbit / s, przesyłanie przez Internet może zająć 70 GB.

umieść plik na stronie ftp, jak próbowałeś, ale z Afryki

wget -c ftp.server.com/filename

-c wznowi przerwane pobieranie

Jeśli używasz systemu Mac OS X lub Linux po obu stronach (?), rsyncByć może najlepszym rozwiązaniem.

Sprawdź strony podręcznika tutaj .

Mail.ru oferuje 100 GB miejsca. W ten sposób możesz przenieść swój plik. Oczywiście musisz umieć mówić po rosyjsku, a może użyć narzędzia do tłumaczenia.

Wiem, że to stare pytanie i ktoś już zasugerował rsync, ale następujący konkretny przykład działał dobrze dla mnie przy przenoszeniu dużych plików między serwerami:

rsync -r -v --progress --partial -e ssh user@remote-system:/path/to/remote/file /path/to/local/destination/

W ten sposób wywołujesz to polecenie po stronie docelowej, tak że rsync pobiera ogromny plik ze zdalnego serwera do lokalnego katalogu. Ten przykład można zmodyfikować tak, aby przechwytywał całe katalogi zamiast tylko jednego pliku.

Miałem taką samą sytuację. serwer docelowy był zdalny, ale w tym samym kraju. więc użyłem Team Viewer - Transfer plików. Działa idealnie na serwerze Windows.