Самый быстрый способ перенести 55 ГБ изображений на новый сервер
В настоящее время у меня есть два сервера CentOS. Мне нужно знать, как и каким самым быстрым способом было бы "сменить" каталог с изображениями и обработать его?
Это самый быстрый способ, который я только что предложил, потому что tarring занимает вечно... Я выполнил команду:
tar cvf imagesbackup.tar images
И я собирался просто проверить это.
Дайте мне знать, если есть более быстрый путь. У меня есть удаленный /SSH доступ к обеим машинам.
8 ответов
Вместо того, чтобы использовать 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"
Я был бы соблазн rsync это по себе - это делает сжатие и хорошо обрабатывает потерю связи.
Если вы просто смените их и ничего больше, это потратит кучу времени с минимальным приростом скорости.
Поэтому простое копирование файлов с помощью переключателей 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, и поскольку это делается для каждого пакета, существует очень детальная проверка целостности, которая выполняется как часть передачи.) Таким образом, протокол Само по себе это происходит медленнее (из-за дополнительных издержек), но успешное завершение передачи фактически означает, что она была передана как единое целое, и нет необходимости в дополнительной проверке.
В дополнение к предложению Пейси md5sum, я бы использовал следующее:
По месту назначения: nc -w5 -l -p 4567 | tar -xvf -
Тогда по источнику: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567
Это все еще tar/untar, и там нет шифрования, но оно напрямую на другой сервер. Запустите их обоих в тандеме (-w5 дает вам 5 секунд благодати.) и смотреть, как это происходит. Если пропускная способность ограничена, добавьте -z к tar на обоих концах.
Одно замечание - не все хосты имеют 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 на удаленном хосте.
Надеюсь это поможет.
Если у вас есть доступ по 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 сжимал передачу. Эта опция будет использовать больше ресурсов процессора, но меньше пропускной способности, так что имейте это в виду.
Есть опция "--progress", которая даст вам переведенный процент, что неплохо, если вам нравятся такие вещи.
Находятся ли они в общей сети, а не для передачи файлов через Интернет? NFS или FTP могут быть намного быстрее, чем издержки SCP, хотя вы потеряете шифрование во время передачи.
Или вы всегда можете использовать смоляные трубы:
(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'
'j' = bzip2, вы можете использовать 'z' для gzip или --lzma, если ваш tar поддерживает это.