Сейчас у меня два сервера CentOS. Мне нужно знать, как и каким самым быстрым способом будет "смолить" каталог изображений и обработать SCP?
Это самый быстрый способ, который я только что предложил, потому что tarring занимает вечность ... Я выполнил команду:
tar cvf imagesbackup.tar images
И я собирался просто закончить это.
Дайте мне знать, если есть более быстрый способ. У меня есть удаленный / SSH-доступ к обеим машинам.
Вместо использования 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 server1 "tar -zc -C /srcdir ./path")
Обратите внимание, что <(cmd) construct является новым для bash и не работает в старых системах. Он запускает программу и отправляет вывод в канал и заменяет этот канал в команду, как если бы это был файл.
Я мог бы легко написать это так:
server2$ tar -zx -C /destination -f <(ssh server1 "tar -zc -C /srcdir ./path")
Или так:
server2$ ssh server1 "tar -zc -C /srcdir ./path" | tar -zx -C /destination
Или вы можете избавить себя от горя и просто использовать rsync:
server1$ rsync -az ./path server2:/destination/
Наконец, помните, что сжатие данных перед передачей уменьшит вашу пропускную способность, но при очень быстром соединении это может фактически заставить операцию больше времени. Это потому, что ваш компьютер может быть не в состоянии сжимать достаточно быстро, чтобы не отставать: если сжатие 100 МБ занимает больше времени, чем требуется для Отправить 100 МБ, тогда быстрее отправить его без сжатия.
В качестве альтернативы вы можете захотеть использовать конвейер для 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, так как она была полезна для OP. Но один комментарий поразил меня новым пониманием. Итак, небольшой поиск предоставил эту полезную информацию. Обратите внимание, что речь идет о 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 поверх 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 поддерживает это.