Самый простой способ быстрой передачи файлов между серверами Linux?

16

Мне нужно перенести файлы с одного сервера CentOS на другой. Передаст 5 МБ файлов примерно каждые 10 минут. Не нужно шифрование.

Что легкого было для быстрой передачи файлов?

Есть ли что-то проще, чем ftp?

Благодарность!

linux file-transfer

— Алекс Л
источник

1

Я верю, что tar над netcat победит

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

Поскольку мне не нужно шифрование, но нужна скорость, я предпочитаю 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. Он не особо болтлив, хорошо справляется с передачей данных с диска на линию и выполняет настолько мало работы, сколько необходимо для выполнения запроса (например, применяет diff для текстовых файлов).

— Офидиан

21

tar over ssh - это нормально, но tar over TCP через netcat требует минимальных затрат! Если это разовая вещь, сделайте это:

На приемнике:

nc -l -p 8989 | tar x

На отправителя:

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

Если это то, что вы собираетесь делать регулярно, я бы, вероятно, использовал rsync.

— Эван Андерсон
источник

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

— чмии

То же самое, что вы не читаете Эвана. Ха ха ха! На самом деле это не разовая вещь. Он сказал, что будет передавать файлы размером 5 МБ каждые 10 минут. Возможно, отправка через азбуку Морзе была бы хорошей альтернативой? ;-) (примечание: личная шутка между мной и Эваном)

— KPWINC

8

Два человека упомянули tar над ssh, но не сказали, как это сделать. Для записи, основная процедура заключается в следующем:

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

Или, если вы хотите начать переводы с получающего конца:

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

Преимущество такого подхода по сравнению с решением Эвана для Netcat заключается в том, что все это можно запустить с одного компьютера; вам не нужно координировать два вызова netcat. Если вам нужно, чтобы это выполнялось автоматически, вы можете настроить ключ ssh, который позволит вам устанавливать соединения без ключевой фразы, и использовать этот ключ для этих соединений.

ssh имеет опцию -C для сжатия своего потока данных, или вы можете использовать встроенную возможность сжатия GNU tar:

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

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

— Kenster
источник

1

+1 Что, ты имеешь в виду, что не все интуитивно знают, как сделать tar поверх ssh? Weird. :)

— хаос

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

— Кило

Какая проверка целостности нужна tar? Уровни TCP и ssh обеспечивают надежную передачу данных. Если вы утверждаете, что сам tar может содержать ошибки, вы должны обращаться с rsync таким же образом. В действительности из-за проблем с протоколом у меня перестал зависать перевод rsync. Я не помню, чтобы какой-нибудь конвейер tar / untar делал это.

— Кенстер

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

— allaryin
источник

3

Rsync - это хороший способ, потому что, если вы обнаружите, что переносите одни и те же файлы более одного раза, это ускорит копирование, как показано в этой цитате со страницы руководства.

   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 и tar. Это будет быстрее, чем ssh, rsync или scp в локальной сети, где шифрование не имеет значения. Гугл "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-адрес удаленного сервера

— Mangia
источник

-1

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

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

или этот:

https://github.com/defunkt/gist

Используйте команду gist для загрузки и скачивания

— Gank
источник

Пожалуйста, предоставьте объяснение, а не только ссылки. Тогда ваш ответ может оказаться полезным, если ссылки станут недействительными.

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