Найпростіший спосіб швидкої передачі файлів між серверами Linux?

16

Мені потрібно передавати файли з одного сервера CentOS на інший. Передаватиме файли по 5 Мб приблизно кожні 10 хвилин. Не потрібно шифрування.

Що легко для швидкої передачі файлів?

Чи є щось простіше, ніж ftp?

Спасибі!

linux file-transfer

— Алекс Л
джерело

1

Я вірю, що смола над Netcat переможе ... хе-хе ...: serverfault.com/questions/18125/…

— Еван Андерсон

Оскільки мені не потрібно шифрування, але мені потрібна швидкість, я віддаю перевагу rsync.

— Алекс Л

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

— Алекс Л

Не редагуйте відповідь на своє запитання, а надішліть її як відповідь. Відкат.

— HopelessN00b

про "швидку" дивіться також unix.stackexchange.com/questions/48399/…

— rogerdpack

25

rsync

Я б використовував rsync, перш ніж я використовував ftp або tftp.

Більше варіантів та (на мій досвід) надійніший переказ.

— KPWINC
джерело

1

Я також виявив, що rsync зазвичай отримує більшу пропускну здатність, ніж будь-що інше (scp, cifs, nfs)

— Ophidian

як щодо переказів http?

— Алекс Л

@Ophidian Ви маєте на увазі використання rsync як демона? Інакше як це може бути швидше, ніж scp, оскільки обидва використовують ssh і є шифрування.

— балки

@balki Так, демон rsync. Це не особливо балакано, робить гарну роботу з подачею даних з диска на лінію, і робить так само мало роботи, як потрібно для заповнення запиту (стосується, наприклад, текстових файлів).

— Офідіан

21

смола над ssh нормально, але tar на TCP через netcat приблизно настільки низька, як ви можете отримати! Якщо це разова річ, спробуйте:

На приймачі:

nc -l -p 8989 | tar x

Про відправника:

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

Якщо це ви збираєтеся регулярно робити, я, ймовірно, використовую rsync.

— Еван Андерсон
джерело

+1 для netcat, нож швейцарської армії

— chmeee

Те саме на те, що ти не читаєш Евана. Ха-ха-ха! Це насправді не разова річ. Він сказав, що збирається передавати файли по 5 Мб приблизно кожні 10 хвилин. Можливо, надсилання через код Морзе було б хорошою альтернативою? ;-) (примітка: приватний анекдот між Еваном і мною)

— KPWINC

8

Двоє людей згадували смолу над ssh, але не сказали, як це зробити. Для запису основна процедура полягає у виконанні:

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

Або, якщо ви хочете розпочати передачу з приймального кінця:

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

Перевага зробити це таким чином над рішенням мережі Evan в тому, що всю справу можна запустити з одного комп’ютера; не потрібно координувати два виклики netcat. Якщо вам потрібно це автоматично запустити, ви можете встановити ключ ssh, який дозволяє встановлювати з'єднання без парольної фрази, і використовувати цей ключ для цих з'єднань.

ssh має можливість -C для стиснення потоку даних, або ви можете використовувати вбудовану здатність стискання GNU tar:

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

Rsync - це ще один варіант, але її сильний варіант полягає в оновленні файлів, які вже є на кінці прийому. Я знайшов це повільніше, ніж scp або tar / ssh при використанні його для передачі файлів, які вже не існують на іншому кінці.

— Кенстер
джерело

1

+1 Що, ви маєте на увазі, що не всі інтуїтивно знають, як робити смола над ssh? Дивно. :)

— хаос

tar, сам по собі, не є надійним - немає перевірки цілісності, проте за допомогою SSH (TLS) ви отримуєте цілісність завдяки здатності TLS виявляти зміни в польоті на дані. Rsync - кращий вибір, а Rsync, оскільки він буде робити кращу перевірку цілісності без шифрування; в заявленому ОП шифруванні не було необхідності.

— Кіло

Яка перевірка цілісності потрібна дьогтю? Шари TCP і ssh забезпечують надійний транспорт даних. Якщо ви стверджуєте, що гусениця може мати помилки, вам доведеться ставитися до rsync таким же чином. Насправді мені передачі rsync заморожувались через проблеми з протоколом. Я не пригадую, щоб так чи інакше це робив трубопровід смол / утар.

— Кенстер

6

Я б використовував scpабо tarбільше ssh, чесно. Шифрування уповільнює ситуацію, але простота налаштування та використання, надійність та (суб'єктивно, звичайно) знайомство змушують мене скористатися хітом, якщо мені справді не потрібна ця швидкість.

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

(Ще в часи SSHv1 ти часто міг це робити -c none, але, мабуть, хтось вирішив, що це дзюджу погано.)

— хаос
джерело

4

Якщо вам доведеться пройти scp / ssh, мої експерименти показують, що найшвидший шифр, включений за замовчуванням в ці дні, є RC4. Ви вказуєте шифр через " -c arcfour " у вашій команді ssh / scp:

для початкової копії:

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

для оновлень:

rsync -e 'ssh -c arcfour' -r foo/ desthost:/destdir

— алларин
джерело

3

Rsync - це хороший шлях, тому що якщо ви не раз передаєте ті самі файли, це прискорить копію, як показано з цією цитатою зі сторінки 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
джерело

2

FTP досить простий, але ще простішим способом може бути створення спільної NFS на одній машині та встановлення на іншій. Тоді копіювання файлів буде полягати у виконанні cp з одного каталогу в інший.

— Swoogan
джерело

залежно від вимог. Наприклад, я б не використовував NFS в Інтернеті.

— Кайл Ходжсон

1

Гарна думка. У такому випадку я рекомендую rsync, оскільки він може відновитись там, де зупинено, якщо буде перервано Також тому, що він передає лише дельту між джерелом та пунктом призначення.

— Swoogan

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

— integratorIT

2

Якщо ви хочете швидкості, ви можете використовувати netcat та смолу. Це буде швидше, ніж ssh, rsync або scp в локальній мережі, де шифрування не викликає особливих проблем. Google "netcat tar".

DestinationServer

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

SourceServer

tar -cz /source/dir | nc DestinationServer 7878

Це, очевидно, вимагає, щоб netcat був фактично встановлений. Google "netcat tar" для отримання додаткової інформації.

— robertmoggach
джерело

1

Я вважаю, що ви вже вирішили свою проблему, але якщо ваш ssh працює на іншому порту (а не на стандартному порту 22), ви можете використовувати це

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

Примітка: - замініть XXXXX на номер порту - замініть 192.16.1.2 на правильний IP віддаленого сервера

— мангія
джерело

-1

https://www.npmjs.org/package/gist-cli

https://github.com/settings/applications#personal-access-tokens

або цей:

https://github.com/defunkt/gist

Використовуйте команду gist для завантаження та завантаження

— Ганк
джерело

Будь ласка, надайте пояснення, а не лише посилання. Тоді ваша відповідь може бути корисною, якщо посилання стануть недійсними.

— Ендрю Шульман