Как быстро скопировать большое количество файлов между двумя серверами

Мне нужно перенести огромное количество mp3-файлов между двумя серверами (Ubuntu). Под огромным я имею в виду около миллиона файлов, которые в среднем 300 КБ. Я пытался с, scpно это заняло бы около недели. (около 500 КБ / с) Если я передаю один файл по HTTP, я получаю 9-10 МБ / с, но я не знаю, как передать их все.

Есть ли способ быстро их перевести?

Я бы порекомендовал tar. Когда деревья файлов уже похожи, rsync работает очень хорошо. Однако, поскольку rsync выполнит несколько проходов анализа для каждого файла, а затем скопирует изменения, это намного медленнее, чем tar для начальной копии. Эта команда, скорее всего, сделает то, что вы хотите. Он будет копировать файлы между компьютерами, а также сохранять как разрешения, так и права доступа пользователей / групп.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Согласно комментарию Макинтоша ниже, это команда, которую вы бы использовали для rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Внешний жесткий диск и доставка в тот же день.

Я бы использовал rsync.

Если вы экспортировали их через HTTP с доступными списками каталогов, вы также можете использовать wget и аргумент --mirror.

Вы уже видите, что HTTP быстрее, чем SCP, потому что SCP шифрует все (и, следовательно, узкие места в процессоре). HTTP и rsync будут двигаться быстрее, потому что они не шифруют.

Вот несколько документов по настройке rsync в Ubuntu: https://help.ubuntu.com/community/rsync

В этих документах говорится о туннелировании rsync через SSH, но если вы просто перемещаете данные по частной локальной сети, вам не нужен SSH. (Я предполагаю, что вы находитесь в частной локальной сети. Если вы получаете 9-10 МБ / с через Интернет, то я хочу знать, какие у вас соединения!)

Вот некоторые другие очень простые документы, которые позволят вам установить относительный небезопасный сервер rsync (без зависимости от SSH): http://transamrit.net/docs/rsync/

Без особых обсуждений используйте netcat, сетевой швейцарский нож. Нет лишних протоколов, вы напрямую копируете в сетевой сокет. пример

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

С большим количеством файлов, если вы используете rsync, я бы попытался получить версию 3 или выше на обоих концах . Причина в том, что меньшая версия будет перечислять каждый файл перед началом передачи. Новая функция называется возрастающей рекурсией .

Новый алгоритм инкрементной рекурсии теперь используется, когда rsync общается с другой версией 3.x. Это запускает передачу быстрее (до того, как все файлы были найдены) и требует гораздо меньше памяти. См. Параметр --recursive на странице руководства для некоторых ограничений.

rsync, как и другие, уже рекомендовал. Если нагрузка на ЦП из-за шифрования является узким местом, используйте другой алгоритм с меньшей нагрузкой на ЦП, такой как blowfish. Например, что-то вроде

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

При перемещении 80 ТБ данных (миллионы крошечных файлов) вчера переключение с rsyncна tar оказалось оказалось намного быстрее , поскольку мы прекратили попытки

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

и переключился на tar...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Так как эти серверы находятся в одной и той же локальной сети, пункт назначения смонтирован в исходной системе по NFS, что и подталкивает. Не делая это еще быстрее, мы решили не сохранять atimeфайлы:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

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

При копировании большого количества файлов я обнаружил, что такие инструменты, как tar и rsync, более неэффективны, чем они должны быть, из-за накладных расходов, связанных с открытием и закрытием многих файлов. Я написал инструмент с открытым исходным кодом, называемый fast-archiver, который быстрее, чем tar, для этих сценариев: https://github.com/replicon/fast-archiver ; это работает быстрее, выполняя многократные параллельные файловые операции.

Вот пример быстрого архиватора и tar на резервной копии более двух миллионов файлов; Для архивации fast-archiver требуется 27 минут, а для tar - 1 час 23 минуты.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Для передачи файлов между серверами вы можете использовать fast-archiver с ssh, например:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Я также использую tar через netcatподход, за исключением того, что предпочитаю использовать socat- гораздо больше возможностей для оптимизации в вашей ситуации - например, путем настройки mss. (Также смейтесь, если хотите, но мне socatлегче вспомнить аргументы, потому что они последовательны). Так что для меня это очень часто встречается в последнее время, так как я перемещаю вещи на новые серверы:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Псевдонимы необязательны.

Другой альтернативой является Unison . В этом случае может быть немного более эффективным, чем Rsync, и несколько проще настроить слушателя.

Похоже, в верхнем ответе может быть несколько опечаток. Это может работать лучше:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Сетевая файловая система (NFS), а затем скопируйте их с помощью любых файлов , например Midnight Commander (mc), Nautilus (из gnome). Я использовал NFS v3 с хорошими результатами.
• Samba (CIFS), а затем скопируйте файлы с тем, что вы хотите, но я понятия не имею, насколько это эффективно.
• HTTP с, wget --mirrorкак предложил Эван Андерсон или любой другой http-клиент. Будьте осторожны, чтобы не иметь никаких неприятных символических ссылок или вводящих в заблуждение файлов индекса. Если у вас есть только MP3, вы должны быть в безопасности.
• rsync . Я использовал его с довольно хорошими результатами, и одной из его приятных особенностей является то, что вы можете прервать и возобновить передачу позже.

Я заметил, что другие люди рекомендовали использовать netcat . Основываясь на своем опыте, я могу сказать, что он медленный по сравнению с другими решениями.

Благодаря замечательному ответу Scott Pack (я раньше не знал, как это сделать с помощью ssh), я могу предложить это улучшение (если bashэто ваша оболочка). Это добавит параллельное сжатие, индикатор прогресса и проверку целостности по всей сетевой ссылке:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvявляется хорошей программой просмотра прогресса для вашего канала и pigzпредставляет собой параллельную программу gzip, которая использует столько потоков, сколько ваш процессор по умолчанию (я думаю, до 8 максимум). Вы можете настроить уровень сжатия так, чтобы он лучше соответствовал соотношению процессоров и пропускной способности сети, и поменять его местами, pxz -9eа также, pxz -dесли у вас гораздо больше процессоров, чем пропускная способность. Вам нужно только убедиться, что две суммы совпадают по завершении.

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

Образец вывода:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Для блочных устройств:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Очевидно, убедитесь, что они имеют одинаковый размер или ограничение с помощью count =, skip =, seek = и т. Д.

Когда я копирую файловые системы таким образом, я часто сначала dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsобнуляю большую часть неиспользуемого пространства, что ускоряет работу xfer.

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

Я бы порекомендовал использовать rsync . Это может быть не так быстро, но, по крайней мере, если это не сработает (или вы отключите его, потому что это занимает слишком много времени), вы можете продолжить с того места, на котором остановились в следующий раз.

Если вы можете соединить 2 машины напрямую, используя гигабитный Ethernet, это, вероятно, будет самым быстрым.

Для 100 Мбит / с теоретическая пропускная способность составляет 12,5 МБ / с, поэтому при 10 МБ / с у вас все хорошо.

Я также повторил бы предложение сделать rsync, вероятно, через ssh. Что-то вроде:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

При скорости 100 Мбит / с ваши процессоры должны иметь возможность обрабатывать шифрование / дешифрование без значительного влияния на скорость передачи данных. И если вы прервете поток данных, вы сможете продолжить с того места, где остановились. Осторожно, с «миллионами» файлов запуск займет некоторое время, прежде чем он действительно что-то передаст.

Я сталкивался с этим, за исключением того, что я переносил логи Oracle.

Вот разбивка

• УПП

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• Rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

Я использовал FTP с большим успехом (где большой успех эквивалентен ~ 700 Мбит / с в сети Gb). Если вы получаете 10 МБ (что соответствует 80 МБ / с), возможно, что-то не так.

Что вы можете рассказать нам об источнике и месте назначения данных? Это один диск на один диск? RAID на USB?

Я знаю, что на этот вопрос уже есть ответ, но если ваша сеть работает медленно на кроссоверном кабеле Гбит / с, что-то абсолютно необходимо исправить.

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

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

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Тогда на отправляющей стороне:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Обладает следующими преимуществами:

• Нет затрат на ЦП для шифрования, которое имеет ssh.
• Он gzip -1обеспечивает легкое сжатие без насыщения процессора, поэтому делает хороший компромисс, обеспечивая небольшую степень сжатия при сохранении максимальной пропускной способности. (Вероятно, это не так выгодно для данных MP3, но не повредит.)
• Если вы можете разбить файлы на группы, вы можете запустить два или более параллельных канала и реально обеспечить насыщение пропускной способности вашей сети.

например,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Примечания:

• Каким бы способом вы ни переводили, я, вероятно, потом запустил бы rsync или unison, чтобы убедиться, что вы все получили.
• Вы можете использовать tarвместо, cpioесли вы предпочитаете.
• Даже если вы в конечном итоге используете ssh, я бы позаботился о том, чтобы оно не использовало само сжатие, а gzip -1вместо этого направил бы себя через себя, чтобы избежать насыщения процессора. (Или, по крайней мере, установите CompressionLevel на 1.)

Простой scp с соответствующими параметрами легко достигнет 9-10 МБ / с по локальной сети:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

С этими параметрами, вероятно, пропускная способность стала в 4 или 5 раз выше, чем без параметров (по умолчанию).

Если у вас есть ftp сервер на стороне src, вы можете использовать ncftpget с сайта ncftp . Он работает с небольшими файлами, так как использует tar внутри себя.

Одно сравнение показывает это: перемещение небольших файлов размером 1,9 ГБ (33926 файлов)

1. Использование scp занимает 11м59с
2. Использование rsync занимает 7м10 с
3. Использование ncftpget занимает 1м20 с

Вы также можете попробовать использовать команду BBCP, чтобы сделать ваш перевод. Это буферизованный параллельный ssh, который действительно кричит. Обычно мы можем получить 90% + линейную скорость при условии, что мы будем поддерживать подачу трубы.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Обычно, мы очень стараемся, чтобы избежать необходимости перемещаться. Мы используем пулы ZFS, к которым мы всегда можем просто «добавить» больше дискового пространства. Но иногда ... тебе просто нужно что-то переместить. Если у нас есть «живая» файловая система, копирование которой может занять часы (или дни), даже если она выполняется в режиме полного взрыва ... мы выполняем двухэтапную процедуру отправки zfs:

1. Сделайте снимок ZFS и перенесите его в новый пул на новом компьютере. Пусть это займет столько времени, сколько потребуется.
2. Сделайте второй снимок и отправьте его как добавочный. Добавочный моментальный снимок включает только (намного меньший) набор изменений, начиная с первого, поэтому он проходит относительно быстро.
3. Как только добавочный снимок завершен, вы можете перевернуть оригинал и обрезать его до новой копии, а время простоя в автономном режиме сведется к минимуму.

Мы также отправляем дампы zfs через BBCP ... это максимизирует использование нашей сети и минимизирует время передачи.

BBCP находится в свободном доступе, вы можете гуглить его, и это прямая компиляция. Просто скопируйте его в ваш / usr / local / bin как на src, так и на компьютерах назначения, и он будет в основном работать.

Я предполагаю, что мой ответ здесь немного запоздал, но я получил хороший опыт использования mc (Midnight Commander) на одном сервере для подключения через SFTP к другому серверу.

Опция подключения через FTP находится в меню «Влево» и «Вправо», введя адрес следующим образом:

/#ftp:name@server.xy/

или же

/#ftp:name@ip.ad.dr.ess/

Вы можете перемещаться и выполнять файловые операции почти как в локальной файловой системе.

Он имеет встроенную опцию для копирования в фоновом режиме, но я предпочитаю использовать экранную команду и отсоединяться от экрана, пока копируется mc (я думаю, что он тоже работает быстрее).

На @scottpack ответ опции rSync

Для отображения хода загрузки используйте «--progess» в качестве опции после -avW в команде, как показано ниже.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Вот быстрый тест для сравнения некоторых методов,

• Источник - 4-ядерный процессор Intel (R) Xeon® (E5-1620, 3,60 ГГц) с 250 Мбит / с и диском SATA.
• Назначение - 6-ядерный процессор Intel (R) Xeon (R) E-2136 с тактовой частотой 3,30 ГГц с полосой пропускания 1 Гбит / с и дисководом SSD

Количество файлов: 9632, Общий размер: 814 МиБ, Средний размер: 84 КиБ

• RSYNC: 1 мин 40,570 с
• RSYNC + СЖАТИЕ: 0m26,519 с
• TAR + NETCAT: 1 мин 58,763 с
• TAR + COMPRESSION + NETCAT: 0m28,009 с

Команда для tar / netcat была:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

rsync или, возможно, вы захотите скопировать его в один файл, а затем scp. Если вам не хватает места на диске, вы можете передать tar непосредственно через ssh во время его создания.

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

Я попробовал несколько инструментов для копирования файла размером 1 ГБ. Результат ниже: HTTP самый быстрый, с wget -c nc секунда в строке scp самый медленный, и пару раз не получалось. Невозможно возобновить rsync, используя ssh в качестве бэкэнда, поэтому результат тот же. В заключение я хотел бы перейти на http с помощью wget -bqc и дать ему немного времени. Надеюсь, что это помогает

Мне пришлось скопировать диск BackupPC на другую машину.

Я использовал rsync.

У машины было 256 МБ памяти.

Процедура, которой я следовал, была следующей:

• выполнено rsyncбез -H(заняло 9 часов)
• когда rsync закончил, я синхронизировал cpoolкаталог и начал с pcкаталога; Я сократил передачу.
• затем перезапускается rsyncс -Hфлагом, и все файлы, жестко связанные в pcкаталоге, были правильно переданы (процедура нашла все настоящие файлы cpoolи затем связала их с pcкаталогом) (заняло 3 часа).

В конце концов я смог проверить df -m, не было ли дополнительного места потрачено.

Таким образом я исключаю проблему с памятью и rsync. Все время я могу проверить производительность, используя top и atop, и, наконец, я передал 165 ГБ данных.