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


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

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

tar cvf imagesbackup.tar images

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

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


60
2017-12-02 12:39


Источник


Sneakernet? - Nick T


Ответы:


Вместо того, чтобы использовать 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/

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

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

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

89
2017-12-03 10:44



Rsync работал красиво - сжимается «на лету», копирует целые папки, возобновляет работу по неработающей ссылке. Все в одной простой команде. Любить это. Это варианты, которые я нашел полезными: z: compress r: recurse = копировать вложенную папку v: verbose. Пример моей команды Rsync: rsync -azvr / src-path / имя_пользователя @ dest_server: / dest / path / - Bastion


У меня возникнет соблазн пересинхронизировать его с самим собой - он сжимает и отлично справляется с потерей ссылок.


66
2017-12-02 12:47



rsync - это именно тот инструмент. - Rich
+1 - Yay rsync! - Evan Anderson
+1, просто навалиться. Кроме того, мне очень нравится rsync. - Steven Monday
Но при использовании rsync вам придется вручную сжимать данные вручную (если вы хотите сохранить сжатые данные) - wlk
Как сохранить сжатый файл (ы) с помощью rsync? - Dolan Antenucci


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

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

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

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

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

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

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

md5sum /images/* > md5sum_new.txt

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

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

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

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


12
2017-12-02 12:47



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


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

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

Затем по источнику: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

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


8
2017-12-02 13:42



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


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

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

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

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

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

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


1
2017-12-02 14:54



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


У вас есть доступ к 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: некоторые файлы не могли быть перенесены (код 23) в main.c (977) [sender = 2.6.9]», проверьте своих пользователей и группы между серверами; у вас может быть несоответствие.

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

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


1
2017-12-03 22:01





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


0
2017-12-02 13:20



разные серверы в удаленных местах - Andrew Fashion


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

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

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


0
2017-12-03 07:08