it-swarm-ru.tech

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

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

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

96
nicudotro

Я бы порекомендовал 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
119
Scott Pack

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

38
Adam

Я бы использовал 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/

17
Evan Anderson

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

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

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

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

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

8
Kyle Brandt

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

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

Перемещая 80 TB данных (миллионы крошечных файлов) вчера, переключаясь с 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 в исходной системе, которая выполняет Push. Не делая это еще быстрее, мы решили не сохранять atime файлов:

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

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

rsync_vs_tar

7
Philip Durbin

При копировании большого количества файлов я обнаружил, что такие инструменты, как 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 [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

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

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

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

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

3
R. Francis Smith
  • Сетевая файловая система (NFS) , а затем скопируйте их, как хотите, например, Полуночный командир (mc), Наутилус (из гнома). Я использовал NFS v3 с хорошими результатами.
  • Samba (CIFS) , а затем скопируйте файлы с тем, что вы хотите, но я понятия не имею, насколько это эффективно.
  • [~ # ~] http [~ # ~] с wget --mirror as предложил Эван Андерсон или любой другой http-клиент. Будьте осторожны, чтобы не иметь никаких неприятных символических ссылок или вводящих в заблуждение индексных файлов. Если у вас есть только MP3, вы должны быть в безопасности.
  • Rsync . Я использовал его с довольно хорошими результатами, и одна из его приятных особенностей заключается в том, что вы можете прервать и возобновить передачу позже.

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

2
Cristian Ciupitu

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

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

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

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]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 [[email protected]]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.

2
Daniel Santos

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

2
Adam D'Amico

Вы не упомянули, находятся ли эти две машины в одной локальной сети, или является ли обязательным безопасный канал (т. Е. С использованием 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 или nison , чтобы убедиться, что вы все получили.
  • Вы можете использовать tar вместо cpio , если хотите.
  • Даже если вы в конечном итоге используете ssh, я бы позаботился о том, чтобы он не использовал само сжатие, и передавал через gzip -1 вместо себя, чтобы избежать насыщения процессора. (Или, по крайней мере, установите CompressionLevel на 1.)
1
Evan

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

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

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

Вы также можете попробовать использовать команду 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, так и на компьютерах назначения, и он будет в основном работать.

1
C. Shamis

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

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

/#ftp:[email protected]/

или

/#ftp:[email protected]/

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

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

1
w-sky

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

scp -C -c arcfour256 ./local/files.mp3 [email protected]:/opt/remote

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

1
user57125

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

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

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

1
Brent

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

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

rsync -avW -e ssh $SOURCE [email protected]$REMOTE:$DEST

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

1
David Mackintosh

Я сталкивался с этим, за исключением того, что я переносил логи 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?

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

1
Matt Simmons

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

  • Источник - 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 -
1
Antares

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

0
Wim ten Brink

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

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

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

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

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

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

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

0
Hector

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

0
Mijo

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

0
Adam Gibbins