Як надсилати величезні файли з одного сервера на інший сервер

Мені потрібно передати величезний файл (понад 70 Гб) з одного сервера в Канаді на інший сервер в Африці.

Я спробував FTP, але завжди десь відключаюсь. І я здогадуюсь, що мережа не є стабільною для африканського сервера, частина файлів завантажена, але коли я відкриваю, він пошкоджується.

Тому мені дуже потрібен інструмент для передачі величезного файлу:

1. Використовуйте пропускну здатність, тому я можу завантажувати його якнайшвидше.
2. Якщо мережа нестабільна, інструмент може її виявити, видалити пошкоджені дані та завантажити знову.
3. Я не хочу завантажувати його в інше місце (як і більшість рішень для спільного використання файлів, завантажувати їх на сервер та отримувати одне посилання)
4. Я віддаю перевагу інструменту, який можна встановити на обох серверах.

ОС є Windows Server 2008 R2 для обох серверів. Я не можу використовувати канал передачі третьої сторони.

BitTorrent може бути хорошим рішенням для вас.

Створіть торрент на початковому сервері, перенесіть файл торрента до пункту призначення, а потім використовуйте одного з клієнтів як треттер Bittorrent. Bittorrent розбиває файл на керовані фрагменти і гарантує, що всі вони передаються без помилок.

Очевидно, що у створенні торрент-файлу є накладні витрати, і немає рою для підвищення швидкості завантаження, але якщо ви маєте справу з шаленим посиланням, це може працювати для вас дуже добре.

FTP жахливо - він народився в середині 1980-х, і, чесно кажучи, він повинен був там померти.

Я, мабуть, почав би з scp (Secure Copy), який повинен бути частиною пакету opensh або openssh-client у вашому улюбленому дистрибутиві Linux (включаючи Cygwin), або доступним у складі пакета PuTTY, якщо ви використовуєте Windows без Cygwin . Вам потрібно буде налаштувати ssh-сервер на хості призначення, але це досить просто, якщо припустити, що у вас є root / Administrator (якщо цього не сталося, все стає складніше); як тільки ви запустите ssh-сервер і отримаєте доступ до нього з вихідного хоста, це лише питання

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

Це має досить добре задовольнити ваш пункт 1, оскільки scp має досить низькі накладні витрати; він, безумовно, повинен відповідати пункту 2, оскільки він обов'язково виявить невдале з'єднання і може бути (ймовірно) налаштований або (звичайно) сценарій, щоб повторити стільки разів, скільки потрібно; він охоплює пункт 3 легко, оскільки проміжний хост або послуга не потрібні; і він також непогано охоплює пункт 4, оскільки ви можете встановити ssh-сервер на обох хостах, а потім перенести файл у будь-якому напрямку. Ви також безкоштовно отримуєте шифрування, яке може вам не корисно.

Посібник з OpenSSH - це, мабуть, добре місце для початку, і я буду радий запропонувати подальшу допомогу, якщо ви закінчите цей шлях - у мене є досвід використання scp / ssh для подібних передач (хоча не з Канади до Африки чи навпаки, а не для одного файлу розміром 70 Гб, я визнаю!)

Сподіваюся, це допомагає!

Думаю, було б непогано розділити файл на кілька маленьких, передати їх, а потім знову зібрати їх на віддалений сервер.

Приклад (в Linux), як розділити і об'єднати, ось тут: http://www.techiecorner.com/107/how-to-split-large-file-into-several-smaller-files-linux/

У вас також має бути щось на кшталт ssh-з'єднання з віддаленим сервером, щоб ви могли зв'язати їх там.

Корисним буде також такий інструмент, як "md5sum", щоб перевірити, чи не передані файли є незмінними, порівнюючи хеші.

Ви можете або написати невеликий скрипт оболонки, щоб автоматизувати деякі речі, щоб ви могли безболісно передавати безліч малих файлів, або зробити це вручну та спробувати з кількома, але більшими шматками ...

Залежно від швидкості завантаження та завантаження (як правило, проблема є завантаженням), ваш найкращий спосіб - записати його на HD і надіслати через FedEx, DHL або подібні програми для того, щоб хтось скопіював його на сервер, якщо це можливо.

Наприклад, якщо швидкість завантаження становить 1 Мбіт / с, ви завантажите 1М / 8 = 128 Кб / с. Отже, не враховуючи жодних "проблем", таких як накладні витрати через шифрування (наприклад, використовуючи scp) або з'єднання не на 100% повну швидкість, вам потрібно буде 70G / 128K = більше 500.000 с або 160 год (більше 6 днів). Якщо ваш зв’язок не дуже стабільний, це займе (можливо, набагато) більше часу.

Я б подумав розмістити файл на наборі DVD-дисків або BD-ROM або 2,5-дюймового жорсткого диска та надіслати їх поштою.

Якщо пропускна здатність завантаження становить 1 Мбіт / с, для перенесення через Інтернет 70 годин може знадобитися 6 днів.

помістіть файл на ftp-сайт, як ви намагалися, але з Африки

wget -c ftp.server.com/filename

-c відновиться перервана завантаження

Якщо ви використовуєте Mac OS X або Linux з обох сторін (?), То, rsyncможливо, найкраща ставка.

Ознайомтесь із сторінками керівництва тут .

Mail.ru пропонує 100 Гб простору. Ви можете перенести свій файл таким чином. Звичайно, ви повинні вміти розмовляти російською або, можливо, користуватися інструментом перекладу.

Я знаю, що це старе питання, і хтось уже запропонував rsync, але наступний конкретний приклад добре працював для мене з переміщенням величезних файлів між серверами:

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

Тим самим ви викликаєте цю команду на стороні призначення, щоб rsync перетягував величезний файл з віддаленого сервера в локальний каталог. Цей приклад може бути змінений на snyc цілі каталоги замість одного файлу.

У мене була така ж ситуація. сервер призначення був віддалений, але в тій же країні. тому я використовував команду перегляду файлів - передача файлів. Він прекрасно працював на сервері Windows.