как я могу лучше всего скопировать большое количество маленьких файлов по scp?

<p>у меня есть каталог с несколькими гигабайтами и несколькими тысячами маленьких файлов. я хочу скопировать его по сети с помощью scp более одного раза. процессорное время на компьютерах источника и назначения дешевое, но накладные расходы сети, добавленные путем копирования каждого файла по отдельности, огромны. я хотел бы распаковать и отправить его, но исходному компьютеру недостаточно места на диске.</p><p>есть ли способ для меня, чтобы передать вывод <code>tar -czf <output> <directory></code> для scp? если нет, есть ли другое простое решение? моя исходная машина старая (sunos), поэтому я бы не стал устанавливать на нее какие-либо вещи.</p>

<p>вы можете передать tar через сеанс ssh:</p><pre><code>$ tar czf - <files> | ssh user@host "cd /wherever && tar xvzf -" 

tar со сжатием bzip2 должен брать на себя как большую нагрузку на сеть, так и на процессор.$ tar -c /path/to/src/dir -jcf - ./ | ssh user@server 'tar -c /path/to/dest/dir -jxf -' </code></pre><p>не используя <code>-v</code> потому что вывод на экран может замедлить процесс. но если вы хотите подробный вывод, используйте его на локальной стороне tar (<code>-jcvf</code>), а не в удаленной части.</p><p>если вы неоднократно копируете один и тот же путь назначения, например, обновляете резервную копию, ваш лучший выбор - rsync со сжатием.</p><pre><code>$ rsync -az -e ssh /path/to/src/dir/ user@server:/path/to/dest/dir/ обратите внимание, что пути src и dest заканчиваются символом /. опять же, не используя -v а также -p флаги специально, добавьте их, если вам нужен подробный вывод.

используйте <a href="http://en.wikipedia.org/wiki/rsync">rsync , он использует ssh.применение:rsync -apz /source/path destination.server:remote/path коммутаторы rsync заботятся о сжатии и информации i-узла. -p отображает прогресс каждого файла.ты можешь использовать scp -c, который включает сжатие, но, если возможно, используйте rsync.

вы можете запустить tar на обоих концах, используя ssh. scp является частью семейства добродетелей ssh, так что вы, вероятно, имеете его с обеих сторон. 8:03am 12 % tar cf - some_directory | ssh dest_host "tar xf -" может также быть способ использовать gzip или bzip2 в конвейере, чтобы уменьшить сетевой трафик.

ответ @ pdo хорош, но можно увеличить скорость с помощью буфера и хорошего сжатия и добавить индикатор выполнения.часто узким местом является сеть, и скорость меняется со временем. следовательно, это помогает буферизовать данные перед их отправкой по сети. это можно сделать с помощью pv.кроме того, обычно можно увеличить скорость с надлежащим алгоритмом сжатия. gzip (как использовалось выше) - это алгоритм быстрого сжатия, но в целом zstandard (zstd) (и для высоких коэффициентов сжатия lzma/lzma2 (xz) будет сжиматься лучше и быстрее одновременно . новые xz и zstd уже имеют многоядерную поддержку. для использования gzip с несколькими ядрами можно использовать pigz.вот пример отправки данных с индикатором выполнения, буферизацией и zstandard сжатием по сети:tar cf - . | pv -perabs $(du -sk . | cut -f 1)k | zstd -14 --long=31 -t0 | pv -qcb 512m | ssh user@host "cd /wherever && pv -qcb 512m | zstd -cd -t0 --long=31 | tar xf -" </code></pre><p>первый <code>pv</code> должен показать прогресс (<em> p </em>), расчетное время (<em> e </em>), скорость передачи (<em> r </em>), средняя скорость (<em> a </em>), общее количество переданных байтов (<em> b </em>). общий размер оценивается с помощью <code>du</code> и добавляется к параметру размера (<em> s </em>). прогресс измеряется до сжатия и буферизации, поэтому он не очень точен, но все же полезен.</p><p><code>zstd</code> используется с настройкой сжатия <em> 14 </em>. это число может быть уменьшено или увеличено в зависимости от скорости сети и процессора, поэтому zstd немного быстрее скорости сети. с четырьмя ядрами на процессоре haswell 3,2 ггц <em> 14 </em> дает скорость около 120 мб/с. в этом примере используется длинный режим <em> 31 </em> (используется окно размером 2 гб, требуется много оперативной памяти, но очень хорошо, например, для сжатия дампов базы данных) , опции <em> t0 </em> устанавливают количество потоков равным количеству ядер. следует помнить, что вместе с длинным режимом эти настройки используют много памяти.</p><p>проблема с zstd заключается в том, что большинство операционных систем не поставляются с версией> = 1.3.4. эта версия необходима для правильной многоядерности и длительной поддержки. если он недоступен, его можно скомпилировать и установить с <a href="https://github.com/facebook/zstd">https://github.com/facebook/zstd</a> всего лишь с помощью <code>make -j4 && sudo make install</code>. вместо zstd можно также использовать xz или pigz. xz медленный, но сжимается очень хорошо (хорошо по сравнению с медленными соединениями), pigz/gzip быстр, но сжимается не очень хорошо. <code>pv</code> затем используется снова, но для буферизации (<code>q</code> для тихого режима, <code>c</code> для режима без сращивания [всегда необходим для буферизации] и <code>b</code> для установки) размер буфера).</p><p>в этом примере буфер также используется на стороне получателя. это часто не нужно (поскольку скорость распаковки и записи на жесткий диск в большинстве случаев выше, чем скорость сети), но обычно также не наносит вреда.</p>

<p>если у вас есть gzip на обоих концах: <code>sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh user@destinationhost "cd destinationdir && gzip -c -d | tar xf -"если у вас нет gzip на исходном компьютере, убедитесь, что вы распаковали его в месте назначения: sourcehost$ cd sourcedir && tar cf - . | compress | ssh user@destinationhost "cd destdir && uncompress | tar xf -"</code></p><p>это было бы быстрее, чем сначала сжать его, затем отправить, затем разархивировать, и это не требует дополнительного дискового пространства с обеих сторон. я выбрал флаг сжатия (z) на tar, потому что он, вероятно, отсутствует на древней стороне.</p>

<p>или вы можете сделать это наоборот, если вам нужно. это означает, что нужно перетаскивать архив по сети, а не выдвигать его, как было предложено. это не решает повторяющуюся часть вашего вопроса, и для этого лучше всего подойдет rsync, но, вероятно, есть ключи tar, чтобы помочь.</p><p>итак на локальной машине:</p><pre><code>ssh remote 'tar zcf - /etc/resolv.conf' | tar zxf - </code></pre><p>лучше всего сначала оказаться в нужном каталоге, либо в конце вы должны использовать ключ -c команды unntaring.</p><p>просто упомянуть об этом на случай, если это необходимо. это для меня, так как в моей ситуации мой локальный сервер отстает от nat, поэтому потребовалось бы некоторое сетевое размышление, чтобы иметь возможность сделать это так, как было упомянуто ранее.</p><p>нтн</p>

<p>или смонтируйте удаленную файловую систему через sshfs</p><pre><code>sshfs user@remotehost:/path/on/remote /path/on/local </code></pre>

<p>хотя он и не самый элегантный, особенно потому, что он не копирует один zip или tar-файл и вдвойне, так как это не помогает уменьшить нагрузку на сеть, мой единственный выбор - использовать <code>scp -r</code>:</p><blockquote> <p><strong> <code>-r</code> </strong></p> <ul> <ul>рекурсивно копировать целые каталоги. обратите внимание, что <code>scp</code> следит за символическими ссылками, встречающимися в обходе дерева.</ul> </ul> <sup>источник: <a href="http://man7.org/linux/man-pages/man1/scp.1.html">scp (1)</a> </sup></blockquote><p>у меня были проблемы с нехваткой места на диске с архивным файлом 30 гб. я думал, что gunzip может сделать это встроенным, то есть, удалив оригинал, так как он был разархивирован (и я, возможно, пропустил результат google), но я ничего не смог найти.</p><p>наконец, потому что я устал от попыток несколько раз ждать, пока новый tar или zip файл будет завершен, tar'ing или zip, я, наконец, просто сделал:</p><ol> <li>с исходного сервера/пк/ноутбука перейдите в каталог, где находится ваша папка с многочисленными файлами/папками.</li> <li><code>scp -r <i>source\_folder\_name</i> <i>yourname</i>@<i>yourservername</i>:<i>destination\_folder\_name</i></code></li> </ol><p>тогда просто возьмите немного пива, кофе или попкорна и подождите. хорошо, что scp будет повторять попытки, если сетевое соединение "зависнет". просто надеюсь, что он не исчезнет полностью.</p>