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

<p>мне нужно перенести огромное количество mp3-файлов между двумя серверами (ubuntu). под огромным я имею в виду около миллиона файлов, которые в среднем 300 кб. я попытался с <code>scp</code>, но это заняло бы около недели. (около 500 кб/с) если я передаю один файл по http, я получаю 9-10 мб/с, но я не знаю, как передать их все.</p><p>есть ли способ перевести их всех быстро?</p>

<p>я бы порекомендовал tar. когда деревья файлов уже похожи, rsync хорошо выполняет <em>очень</em>. однако, поскольку rsync выполнит несколько проходов анализа для каждого файла, а затем скопирует изменения, это намного медленнее, чем tar для начальной копии. эта команда, скорее всего, сделает то, что вы хотите. он будет копировать файлы между компьютерами, а также сохранять как разрешения, так и права доступа пользователей/групп.</p><pre><code>tar -c /path/to/dir | ssh remote\_server 'tar -xvf - -c /absolute/path/to/remotedir' </code></pre><p>согласно комментарию макинтоша ниже, это команда, которую вы бы использовали для rsync.</p><pre><code>rsync -avw -e ssh /path/to/dir/ remote\_server:/path/to/remotedir </code></pre>

<p>внешний жесткий диск и доставка в тот же день.</p>

<p>я бы использовал rsync.</p><p>если вы экспортировали их через http с доступными списками каталогов, вы также можете использовать wget и аргумент --mirror.</p><p>вы уже видите, что http быстрее, чем scp, потому что scp шифрует все (и, следовательно, узкие места в процессоре). http и rsync будут двигаться быстрее, потому что они не шифруют.</p><p>вот несколько документов по настройке rsync в ubuntu: <a href="https://help.ubuntu.com/community/rsync">https://help.ubuntu.com/community/rsync</a> </p><p>в этих документах говорится о туннелировании rsync через ssh, но если вы просто перемещаете данные по частной локальной сети, вам не нужен ssh. (я предполагаю, что вы находитесь в частной локальной сети. если вы получаете 9-10 мб/с через интернет, то я хочу знать, какие у вас соединения!)</p><p>вот некоторые другие очень простые документы, которые позволят вам установить относительный небезопасный сервер rsync (без зависимости от ssh): <a href="http://transamrit.net/docs/rsync/">http://transamrit.net/docs/rsync/</a> </p>

<p>без особых обсуждений используйте netcat, сетевой швейцарский нож. нет лишних протоколов, вы напрямую копируете в сетевой сокет. пример</p><pre><code>srv1$ tar cfv - mp3 | nc -w1 remote.server.net 4321 srv2$ nc -l -p 4321 |tar xfv - </code></pre>

<p>с большим количеством файлов, если вы используете rsync, <strong>я бы попытался получить версию 3 или выше на обоих концах</strong>. причина в том, что меньшая версия будет перечислять каждый файл перед началом передачи. новая функция называется <strong><em> incremental-recursion </em></strong>.</p><blockquote> <p>новый алгоритм инкрементной рекурсии теперь используется, когда rsync общается с другой версией 3.x. это запускает передачу быстрее (до того, как все файлы были найдены) и требует гораздо меньше памяти. см. параметр --recursive на странице руководства для некоторых ограничений.</p> </blockquote>

<p>rsync, как и другие, уже рекомендовал. если нагрузка на цп из-за шифрования является узким местом, используйте другой алгоритм с меньшей нагрузкой на цп, такой как blowfish. например. что-то вроде</p><p><code>rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path</code></p>

<p>перемещая 80 tb данных (миллионы крошечных файлов) вчера, переключаясь с <code>rsync</code> на <code>tar</code> <a href="http://sjoeboo.github.com/blog/2012/04/03/rsync-vs-tar/">оказалось намного быстрее</a> , как мы перестали пытаться</p><pre><code># slow rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01 </code></pre><p>и вместо этого переключился на <code>tar</code> ...</p><pre><code># fast cd /mnt/backups/ tar -cf - section01 | tar -xf - -c /mnt/destination01/ </code></pre><p>поскольку эти серверы находятся в одной и той же локальной сети, место назначения смонтировано на nfs в исходной системе, которая выполняет push. не делая это еще быстрее, мы решили не сохранять <code>atime</code> файлов:</p><pre><code>mount -o remount,noatime /mnt/backups mount -o remount,noatime /mnt/destination01 </code></pre><p>на приведенном ниже рисунке показана разница, произошедшая при переходе от rsync к tar. это была моя идея <a href="http://about.me/jcuff">босса</a> и моя <a href="http://mattynick.com">коллега</a> и выполнили ее, и сделали великолепную <a href="http://sjoeboo.github.com/blog/2012/04/03/rsync-vs-tar/">запись в его блоге</a> . мне просто нравится <a href="http://www.flickr.com/groups/webopsviz/">красивые картинки</a> . :)</p><p><img src="https://i.stack.imgur.com/6igqi.png" alt="rsync\_vs\_tar"></p>

<p>при копировании большого количества файлов я обнаружил, что такие инструменты, как tar и rsync, более неэффективны, чем должны быть из-за накладных расходов, связанных с открытием и закрытием многих файлов. я написал инструмент с открытым исходным кодом, называемый fast-archiver, который быстрее, чем tar, для следующих сценариев: <a href="https://github.com/replicon/fast-archiver">https://github.com/replicon/fast-archiver</a> ; это работает быстрее, выполняя многократные параллельные файловые операции.</p><p>вот пример быстрого архивирования и tar на резервной копии более двух миллионов файлов; fast-archiver занимает 27 минут, а tar - 1 час 23 минуты.</p><pre><code>$ 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 </code></pre><p>для передачи файлов между серверами вы можете использовать fast-archiver с ssh, например:</p><pre><code>ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x </code></pre>

<p>я также использую подход tar через <code>netcat</code>, за исключением того, что предпочитаю использовать <code>socat</code> - гораздо больше возможностей для оптимизации в вашей ситуации - например, путем настройки mss. (также смейтесь, если хотите, но я считаю, что аргументы <code>socat</code> легче запомнить, потому что они последовательны). так что для меня это очень часто встречается в последнее время, так как я перемещаю вещи на новые серверы:</p><pre><code>host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum host2$ socat tcp4-listen:portnum stdout | tar xvpf - </code></pre><p>псевдонимы необязательны.</p>

<ul> <li><strong> сетевая файловая система (nfs) </strong>, а затем скопируйте их, как хотите, например, полуночный командир (mc), наутилус (из гнома). я использовал nfs v3 с хорошими результатами.</li> <li><strong> samba (cifs) </strong>, а затем скопируйте файлы с тем, что вы хотите, но я понятия не имею, насколько это эффективно.</li> <li><strong> [~ # ~] http [~ # ~] </strong> с <code>wget --mirror</code> as <a href="https://serverfault.com/users/7200/evan-anderson">предложил эван андерсон</a> или любой другой http-клиент. будьте осторожны, чтобы не иметь никаких неприятных символических ссылок или вводящих в заблуждение индексных файлов. если у вас есть только mp3, вы должны быть в безопасности.</li> <li><strong> rsync </strong>. я использовал его с довольно хорошими результатами, и одна из его приятных особенностей заключается в том, что вы можете прервать и возобновить передачу позже.</li> </ul><p>я заметил, что другие люди рекомендовали использовать <em> netcat</em>. исходя из <em> моего опыта</em> с его помощью я могу сказать, что он медленный по сравнению с другими решениями.</p>

<p>похоже, в верхнем ответе может быть несколько опечаток. это может работать лучше:</p><pre><code>tar -cf - /path/to/dir | ssh remote\_server 'tar -xvf - -c /path/to/remotedir' </code></pre>

<p>благодаря замечательному ответу scott pack (я не знал, как это сделать с ssh раньше), я могу предложить это улучшение (если <code>bash</code> - ваша shell). это добавит параллельное сжатие, индикатор прогресса и проверку целостности по всей сетевой ссылке:</p><pre><code>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 ' </code></pre><p><code>pv</code> - это хорошая программа для просмотра прогресса для вашего канала, а <code>pigz</code> - параллельная программа gzip, которая использует столько потоков, сколько у вашего процессора по умолчанию (я думаю, до 8 максимум). вы можете настроить уровень сжатия, чтобы он лучше подходил соотношению пропускной способности цп и сети и поменять его местами с помощью <code>pxz -9e</code> а также <code>pxz -d</code> если у вас гораздо больше процессора, чем пропускная способность. вам нужно только убедиться, что две суммы совпадают по завершении.</p><p>эта опция полезна для очень больших объемов данных, а также для сетей с высокой задержкой, но не очень полезна, если связь нестабильна и обрывается. в этих случаях rsync, вероятно, является лучшим выбором, поскольку он может возобновиться.</p><p>пример вывода:</p><pre><code>6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e - ] 176mib [9.36mib/s] [9.36mib/s] [ <=> ] 6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e - </code></pre><p>для блочных устройств:</p><pre><code>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 ' </code></pre><p>очевидно, убедитесь, что они имеют одинаковый размер или ограничение с помощью count =, skip =, seek = и т.д.</p><p>когда я копирую файловые системы таким образом, я часто сначала <code>dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs</code> обнулить большую часть неиспользуемого пространства, что ускоряет работу xfer.</p>

<p>другая альтернатива <a href="http://www.cis.upenn.edu/~bcpierce/unison/">nison</a> . в этом случае может быть немного более эффективным, чем rsync, и несколько проще настроить слушателя.</p>

<p>вы не упомянули, находятся ли эти две машины в одной локальной сети, или является ли обязательным безопасный канал (т. е. с использованием ssh), но другой инструмент, который вы можете использовать, --- <a href="http://netcat.sourceforge.net/">netcat</a> .</p><p>я бы использовал следующее на принимающей машине:</p><pre><code>cd <destdir> netcat -l -p <port> | gunzip | cpio -i -d -m </code></pre><p>тогда на отправляющей стороне:</p><pre><code>cd <srcdir> find . -type f | cpio -o | gzip -1 | netcat <desthost> <port> </code></pre><p>имеет следующие преимущества:</p><ul> <li>нет затрат на цп для шифрования, которое имеет ssh.</li> <li><code>gzip -1</code> обеспечивает легкое сжатие без насыщения процессора, что делает его хорошим компромиссом, обеспечивая небольшое сжатие при сохранении максимальной пропускной способности. (вероятно, это не так выгодно для данных mp3, но не повредит.)</li> <li>если вы можете разбить файлы на группы, вы можете запустить два или более параллельных канала и реально обеспечить насыщение пропускной способности сети.</li> </ul><p>например.,</p><pre><code>find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone> find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo> </code></pre><p>ноты:</p><ul> <li>каким бы способом вы ни переводили, я бы, вероятно, запустил rsync или <a href="http://www.cis.upenn.edu/~bcpierce/unison/">nison</a> , чтобы убедиться, что вы все получили.</li> <li>вы можете использовать <code>tar</code> вместо <a href="http://www.manpagez.com/info/cpio/"><code>cpio</code></a> , если хотите.</li> <li>даже если вы в конечном итоге используете ssh, я бы позаботился о том, чтобы он не использовал само сжатие, и передавал через <code>gzip -1</code> вместо себя, чтобы избежать насыщения процессора. (или, по крайней мере, установите compressionlevel на 1.)</li> </ul>

<p>если у вас есть сервер ftp на стороне src, вы можете использовать <strong> ncftpget </strong> из <a href="http://www.ncftp.com">сайт ncftp</a> . он работает с небольшими файлами, так как использует tar внутри себя.</p><p>одно сравнение показывает это: перемещение небольших файлов размером 1,9 гб (33926 файлов)</p><ol> <li>использование scp занимает 11м59с</li> <li>использование rsync занимает 7м10 с</li> <li>использование ncftpget занимает 1м20 с</li> </ol>

<p>вы также можете попробовать использовать команду bbcp, чтобы сделать ваш перевод. это буферизованный параллельный ssh, который действительно кричит. обычно мы можем получить 90% + линейную скорость при условии, что мы будем поддерживать подачу трубы.</p><pre><code>$ bbcp -s 8 -w 64m -n io 'tar -co srcdirectory' desthostname:'tar -x -c destdir' обычно, мы очень стараемся, чтобы избежать необходимости перемещаться. мы используем пулы zfs, к которым мы всегда можем просто "добавить" больше дискового пространства. но иногда ... тебе просто нужно что-то переместить. если у нас есть "живая" файловая система, копирование которой может занять часы (или дни), даже если она выполняется в режиме полного взрыва ... мы выполняем двухэтапную процедуру отправки zfs: сделайте снимок zfs и перенесите его в новый пул на новом компьютере. пусть это займет столько времени, сколько потребуется. сделайте второй снимок и отправьте его как добавочный. добавочный моментальный снимок включает только (намного меньший) набор изменений, начиная с первого, поэтому он проходит относительно быстро. как только добавочный снимок завершен, вы можете перевернуть оригинал и обрезать его до новой копии, а время простоя в автономном режиме сведется к минимуму. мы также отправляем дампы zfs через bbcp ... это максимизирует использование нашей сети и минимизирует время передачи.bbcp находится в свободном доступе, вы можете гуглить его, и это прямая компиляция. просто скопируйте его в ваш/usr/local/bin как на src, так и на компьютерах назначения, и он будет в основном работать.

я предполагаю, что мой ответ здесь немного запоздал, но я получил хороший опыт использования mc (midnight commander) на одном сервере для соединения через sftp с другим сервером.опция подключения через ftp находится в меню "влево" и "вправо", введя адрес следующим образом:/#ftp:name@server.xy/ или/#ftp:name@ip.ad.dr.ess/ вы можете перемещаться и выполнять файловые операции почти как в локальной файловой системе.он имеет встроенную опцию для копирования в фоновом режиме, но я предпочитаю использовать экранную команду и отсоединяться от экрана, пока копируется mc (я думаю, что он тоже работает быстрее).

простой scp с соответствующими параметрами легко достигнет 9-10 мб/с по локальной сети:scp -c -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote с этими параметрами, вероятно, пропускная способность стала в 4 или 5 раз выше, чем без параметров (по умолчанию).

я не думаю, что вы добьетесь большего успеха, чем scp, если не установите более быстрые сетевые карты. если вы делаете это через интернет, это не поможет.я бы порекомендовал использовать <strong>rsync</strong>. это может быть не так быстро, но, по крайней мере, если это не сработает (или вы отключите его, потому что это занимает слишком много времени), вы можете продолжить с того места, на котором остановились в следующий раз.если вы можете соединить 2 машины напрямую, используя гигабитный ethernet, это, вероятно, будет самым быстрым.

для 100 мбит/с теоретическая пропускная способность составляет 12,5 мб/с, поэтому при 10 мб/с у вас все хорошо.я также повторил бы предложение сделать rsync, вероятно, через ssh. что-то вроде:rsync -avw -e ssh $source $user@$remote:$dest </code></pre><p>при скорости 100 мбит/с ваши процессоры должны иметь возможность обрабатывать шифрование/дешифрование без значительного влияния на скорость передачи данных. и если вы прервете поток данных, вы сможете продолжить с того места, где остановились. осторожно, с "миллионами" файлов запуск займет некоторое время, прежде чем он действительно что-то передаст.</p>

<p>я сталкивался с этим, за исключением того, что я переносил логи oracle.</p><p>вот разбивка</p><ul> <li> <p>упп</p> <pre><code>inefficient and encrypted (encrypted = slower than unencrypted depending on the link and your processor) </code></pre></li> <li> <p>rsync</p> <pre><code>efficient but typically encrypted (though not necessarily) </code></pre></li> <li> <p>ftp/http</p> <pre><code>both seem to be efficient, and both are plaintext. </code></pre></li> </ul><p>я использовал ftp с большим успехом (где большой успех эквивалентен ~ 700 мбит/с в сети gb). если вы получаете 10 мб (что соответствует 80 мб/с), возможно, что-то не так.</p><p>что вы можете рассказать нам об источнике и месте назначения данных? это один диск на один диск? raid на usb?</p><p>я знаю, что на этот вопрос уже есть ответ, но если ваша сеть работает медленно на кроссоверном кабеле гбит/с, что-то абсолютно необходимо исправить.</p>

<p>вот быстрый тест для сравнения некоторых методов,</p><ul> <li>источник - 4-ядерный процессор intel (r) xeon e5-1620 с частотой 3,60 ггц, 250 мбит/с и диском sata.</li> <li>назначение - 6-ядерный процессор intel (r) xeon (r) e-2136 с тактовой частотой 3,30 ггц с полосой пропускания 1 гбит/с и дисководом ssd</li> </ul><p>количество файлов: 9632, общий размер: 814 миб, средний размер: 84 киб</p><ul> <li>rsync: 1 мин 40,570 с</li> <li>rsync + сжатие: 0m26,519 с</li> <li>tar + netcat: 1 мин 58,763 с</li> <li>tar + compression + netcat: 0m28,009 с</li> </ul><p>команда для tar/netcat была:</p><pre><code>source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000 dest : nc -v -l 5000 | tar -xf - </code></pre>

<p>если вы отправляете файлы в формате mp3 и другие сжатые файлы, вы ничего не получите от любого решения, которое пытается дополнительно сжать эти файлы. решением было бы то, что может создать несколько соединений между обоими серверами и таким образом увеличить нагрузку на пропускную способность между двумя системами. как только это достигнет максимума, мало что можно получить без улучшения вашего оборудования. (более быстрые сетевые карты между этими серверами, например.)</p>

<p>мне пришлось скопировать диск backuppc на другую машину.</p><p>я использовал rsync.</p><p>у машины было 256 мб памяти.</p><p>процедура, которой я следовал, была следующей:</p><ul> <li>исполнено <code>rsync</code> без <code>-h</code> (заняло 9 часов)</li> <li>когда rsync закончил, я синхронизировал каталог <code>cpool</code> и начал с каталога <code>pc</code>; я сократил передачу.</li> <li>затем перезапустил <code>rsync</code> с помощью <code>-h</code> \_, и все файлы, жестко связанные в каталоге <code>pc</code>, были правильно переданы (процедура нашла все реальные файлы в <code>cpool</code> и затем сошлась с каталогом <code>pc</code>) ( заняло 3 часа).</li> </ul><p>в конце концов я мог проверить с помощью <code>df -m</code> что лишнего места не было потрачено.</p><p>таким образом я исключаю проблему с памятью и rsync. все время я могу проверить производительность, используя top и atop, и, наконец, я передал 165 гб данных.</p>

<p>я попробовал несколько инструментов для копирования файла размером 1 гб. результат ниже: http самый быстрый, с wget -c nc секунда в строке scp самый медленный, и пару раз не получалось. невозможно возобновить rsync, используя ssh в качестве бэкэнда, поэтому результат тот же. в заключение я хотел бы перейти на http с помощью wget -bqc и дать ему немного времени. надеюсь, что это помогает</p>

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