Самый быстрый способ перенести 55 ГБ изображений на новый сервер

64

В настоящее время у меня есть два сервера CentOS. Мне нужно знать, как и каким самым быстрым способом было бы «скопировать» каталог с изображениями и обработать его?

Это самый быстрый способ, который я только что предложил, потому что tarring занимает вечно ... Я выполнил команду:

tar cvf imagesbackup.tar images

И я собирался просто проверить это.

Дайте мне знать, если есть более быстрый путь. У меня есть удаленный / SSH доступ к обеим машинам.

Андрей Мод
источник
12
Sneakernet?
Ник T

Ответы:

98

Вместо того, чтобы использовать tar для записи на локальный диск, вы можете писать напрямую на удаленный сервер по сети, используя ssh.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Любая строка, которая следует за вашей командой "ssh", будет запущена на удаленном сервере вместо интерактивного входа. Вы можете направлять ввод / вывод в и из этих удаленных команд через SSH, как если бы они были локальными. Помещение команды в кавычки позволяет избежать путаницы, особенно при использовании перенаправления.

Или вы можете извлечь файл tar непосредственно на другом сервере:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Обратите внимание на редко используемый -Cпараметр. Это означает «сначала перейдите в этот каталог, прежде чем что-либо делать».

Или, возможно, вы хотите «вытащить» с сервера назначения:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Обратите внимание, что <(cmd) конструкция является новой для bash и не работает на старых системах. Он запускает программу и отправляет вывод в канал и подставляет этот канал в команду, как если бы это был файл.

Я мог бы просто написать вышеизложенное следующим образом:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Или следующим образом:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Или вы можете избавить себя от горя и просто использовать rsync:

server1$ rsync -az ./path server2:/destination/

Наконец, помните, что сжатие данных перед передачей уменьшит вашу пропускную способность, но при очень быстром соединении это может фактически сделать операцию более длительной . Это связано с тем, что ваш компьютер может быть не в состоянии сжимать достаточно быстро, чтобы не отставать: если сжатие 100 МБ занимает больше времени, чем требуется для отправки 100 МБ, то быстрее отправить его без сжатия.

С другой стороны, вы можете захотеть использовать pzip для gzip самостоятельно (вместо использования опции -z), чтобы вы могли указать уровень сжатия. По моему опыту, при быстрых сетевых подключениях со сжимаемыми данными использование gzip на уровне 2 или 3 (по умолчанию 6) дает наилучшую общую пропускную способность в большинстве случаев. Вот так:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
tylerl
источник
Rsync работал прекрасно - сжимает на лету, копирует целые папки, возобновляет работу по неработающей ссылке. Все в одной простой команде. Любить это. Вот варианты, которые я нашел полезными: z: сжатие r: recurse = копировать подпапку v: подробный. Пример моей команды Rsync: rsync -azvr / src-path / username @ dest_server: / dest / path /
Бастион
68

Я был бы соблазн rsync это по себе - это делает сжатие и хорошо обрабатывает потерю связи.

Chopper3
источник
14
rsync - это абсолютно правильный инструмент.
Богатое
4
+1 - Yay rsync!
Эван Андерсон
1
+1, просто наваливать. Плюс, мне действительно нравится rsync.
Стивен Понедельник
1
Но при использовании rsync вам все равно придется сжимать данные вручную (если вы хотите хранить сжатые данные)
wlk
Как вы можете хранить сжатые файлы с rsync?
Долан Антенуччи
12

Если вы просто смените их и ничего больше, это потратит кучу времени с минимальным приростом скорости.

Поэтому простое копирование файлов с помощью переключателей cvf будет эффективно стоить времени, необходимого для чтения всех изображений 55 ГБ и их записи на диск. (Фактически, это будет потрачено еще больше времени, поскольку это приведет к значительным накладным расходам).

Здесь вы получаете только одно преимущество: уменьшаются накладные расходы на загрузку множества файлов. Вы можете получить более быстрое время передачи, если сжимаете изображения (но, поскольку я считаю, что они уже находятся в сжатом формате, это не сильно поможет). Просто больше трата вычислительного времени.

Самый большой недостаток передачи огромного архива tar по проводам заключается в том, что если что-то пойдет не так, это может означать, что вам придется начинать все сначала.

Я бы использовал этот способ:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

На новом сервере

md5sum /images/* > md5sum_new.txt

А потом просто diff. А поскольку scp поддерживает сжатие на лету, нет необходимости в отдельных архивах.

редактировать

Я буду хранить информацию MD5, так как она была полезна для ОП. Но один комментарий поразил меня новым пониманием. Поэтому немного поиска предоставило эту полезную информацию. Обратите внимание, что предметом здесь является SFTP, а не SCP .

В отличие от FTP, SFTP увеличивает накладные расходы при передаче файлов. Когда файл передается между клиентом и сервером, он разбивается на более мелкие фрагменты, называемые «пакетами». Например, предположим, что каждый пакет имеет размер 32 КБ. Протокол SFTP выполняет проверку контрольной суммы для каждого файла размером 32 КБ по мере его отправки и включает эту контрольную сумму вместе с этим пакетом. Получатель получает этот пакет и дешифрует данные, а затем проверяет контрольную сумму. Сама контрольная сумма «сильнее» контрольной суммы CRC32. (Поскольку SFTP использует 128-битную или более высокую контрольную сумму, такую ​​как MD5 или SHA, и поскольку это делается для каждого пакета, существует очень детальная проверка целостности, которая выполняется как часть передачи.) Таким образом, протокол само по себе медленнее (из-за дополнительных издержек), но успешное завершение передачи означает, де-факто,

Pacey
источник
Большое спасибо, что делает md5sum? а что такое diff? Спасибо, выступаем сейчас!
Andrew Fashion
2
md5sum (или md5) принимает контрольную сумму файлов. Diff ищет различия в файлах (man diff). Контрольная сумма создает строку, хэш, который, если файл изменяется при передаче ... немного перевернут, ошибка ... не будет совпадать, если вы снова возьмете его с другой стороны. Для больших файлов повышается вероятность ошибок. Вот почему, когда вы видите сайты, которые позволяют загружать файлы .iso, они часто имеют контрольную сумму MD5, чтобы вы могли сравнить загруженный файл с тем, чтобы убедиться, что он соответствует и не поврежден.
Барт Сильверстрим
3
scp зашифрован и гарантирует целостность по линии. Существует небольшая вероятность того, что данные были повреждены в памяти или на диске, конечно, но это довольно редко.
Райан Бэйр
1
Действительно ли накладные расходы контрольных сумм SFTP имеют какое-либо практическое значение? Я не могу себе это представить. 4 байта на каждые 32768 не кажутся значимыми. Это 128 кБ на ГБ. Называть это «медленнее» кажется преувеличением во всем, кроме скучного теоретического смысла.
underscore_d
8

В дополнение к предложению Пейси md5sum, я бы использовал следующее:

По месту назначения: nc -w5 -l -p 4567 | tar -xvf -

Тогда по источнику: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Это все еще tar / untar, и там нет шифрования, но оно напрямую на другой сервер. Запустите их обоих в тандеме ( -w5дает вам 5 секунд отсрочки) и наблюдайте за ходом. Если пропускная способность ограничена, добавьте -z к tar на обоих концах.

SmallClanger
источник
1
Я думаю, что наоборот, сначала он должен выполнить в пункте назначения (чтобы открыть сокет), а затем в источнике (для отправки)
Dimitrios Mistriotis
вместо конечного сервера, я должен просто поставить root@1.1.1.1?
Andrew Fashion
Нет, просто IP. netcat не использует протокол, отличный от TCP :) Эта команда также будет самой быстрой из всех приведенных выше команд. В источнике имеется ровно одно чтение на файл, точный минимальный сетевой трафик для передачи файлов и ровно одна запись на файл в месте назначения. Если у вас есть свободные циклы ЦП, добавление флага -z (для сжатия) еще больше ускорит его, поскольку нужно будет передавать меньше сетевых данных.
Джефф МакДжанкин
@ user36845 - Верно. Я не имел в виду хронологию с приведенным выше порядком, но вы правы, сначала нужно будет открыть сокет. Я отредактирую это, чтобы уточнить. :)
SmallClanger
Я не уверен, почему ssh / scp работали со скоростью 125 МБ / с до 133 МБ / с, но netcat легко передает эти данные со скоростью ~ 380 МБ / с (та же ссылка)
ThorSummoner
1

Одно замечание - не все хосты имеют rsync и могут иметь разные версии tar. По этой причине можно рекомендовать в качестве первого порта вызова использование часто игнорируемого cpio.

Вы можете использовать cpio over ssh для произвольной репликации структур файлов / каталогов между хостами. Таким образом, вы получаете более точный контроль над тем, что отправляется, если вы видите, что вам нужно «кормить» cpio, nom-nom. Кроме того, он более переносим для аргументов, cpio мало что меняет - это важный момент, если вы присматриваете за несколькими хостами в гетерогенной среде.

Пример копирования / экспорта / home и его подкаталогов на удаленный хост:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Выше будет скопировать содержимое / export / home и любых его подкаталогов в / export / home на удаленном хосте.

Надеюсь это поможет.

Rowley
источник
Он упомянул, что это были два блока CentOS, поэтому они будут иметь rsync и совместимые с файлами версии tar. Такие инструменты, как rsync, были созданы, чтобы заменить такие инструменты, как cpio :). Вы не можете «возобновить» с помощью cpio, по крайней мере, не зная, с чего именно вы хотите начать, и отфильтруйте свою находку соответствующим образом. Что является ненужным временем накладных расходов. Сказав это, полезная информация для «старых» коробок UNIX :)
Rafiq Maniar
Да, этот cmmand потерял меня, ха-ха
Andrew Fashion
1

Если у вас есть доступ по SSH, у вас есть доступ rsync.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

или же

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Если вы получаете сообщение об ошибке типа «rsync error: некоторые файлы не могут быть переданы (код 23) на main.c (977) [sender = 2.6.9]», проверьте вашего пользователя и группы между серверами; Вы можете иметь несоответствие.

Используйте опцию rsync "-z", если вы хотите, чтобы rsync сжимал передачу. Эта опция будет использовать больше ресурсов процессора, но меньше пропускной способности, так что имейте это в виду.

Есть опция «--progress», которая даст вам переведенный процент, что неплохо, если вам нравятся подобные вещи.

quinnr
источник
0

Находятся ли они в общей сети, а не для передачи файлов через Интернет? NFS или FTP могут быть намного быстрее, чем издержки SCP, хотя вы потеряете шифрование во время передачи.

Tex
источник
разные серверы в удаленных местах
Andrew Fashion
0

Или вы всегда можете использовать смоляные трубы:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, вы можете использовать 'z' для gzip или --lzma, если ваш tar поддерживает это.

OneOfOne
источник