Я часто отправляю папки с 10–100 тыс. Файлов на удаленную машину (в пределах одной сети в кампусе).

Мне просто интересно, есть ли основания полагать, что

 tar + rsync + untar

Или просто

 tar (from src to dest) + untar

может быть быстрее на практике, чем

rsync 

при передаче файлов в первый раз .

Я заинтересован в ответе, который рассматривает вышеупомянутое в двух сценариях: использование сжатия и не использование его.

Обновить

Я только что провел несколько экспериментов, перемещая 10000 небольших файлов (общий размер = 50 МБ), и tar+rsync+untarбыл значительно быстрее, чем rsyncпрямой (оба без сжатия).

Когда вы отправляете тот же набор файлов, rsyncлучше подходит, потому что он будет отправлять только различия. tarвсегда будет отправлять все, и это пустая трата ресурсов, когда много данных уже там. В tar + rsync + untarэтом случае утрачивается это преимущество, а также преимущество синхронизации папок rsync --delete.

Если вы копируете файлы в первый раз, сначала упаковывая, затем отправляя, а затем распаковывая (AFAIK rsyncне принимает ввод по каналу), это rsyncбудет громоздко и всегда хуже, чем просто rsyncing, потому что не нужно будет выполнять какую-либо задачу больше, чем в tarлюбом случае.

Совет: rsync версии 3 или новее выполняет инкрементную рекурсию, что означает, что он начинает копировать почти сразу же, прежде чем считает все файлы.

Совет 2: Если вы используете rsyncболее ssh, вы также можете использовать либоtar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

или просто scp

scp -Cr srcdir user@server:destdir

Общее правило, будь проще.

ОБНОВИТЬ:

Я создал 59M демо-данных

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

и несколько раз проверил передачу файла на удаленный сервер (не в той же локальной сети), используя оба метода

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

сохраняя отдельные журналы от отправленных пакетов трафика ssh

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

В этом случае я не вижу никакого преимущества в меньшем сетевом трафике, используя rsync + tar, что ожидается, когда значение по умолчанию mtu равно 1500, а размер файлов - 10 КБ. rsync + tar генерировал больше трафика, работал медленнее в течение 2-3 секунд и оставил два мусорных файла, которые нужно было очистить.

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

Возможно, rsync + tar будет лучше, чем просто rsync для гораздо большего набора данных. Но, честно говоря, я не думаю, что это стоит того, вам нужно двойное пространство с каждой стороны для упаковки и распаковки, и есть несколько других вариантов, как я уже упоминал выше.

rsyncтакже делает сжатие. Используйте -zфлаг. Если вы работаете поверх ssh, вы также можете использовать режим сжатия ssh. Мне кажется, что повторные уровни сжатия бесполезны; это просто сожжет циклы без существенного результата. Я бы порекомендовал поэкспериментировать со rsyncсжатием. Это кажется довольно эффективным. И я бы рекомендовал пропустить использование tarили любое другое сжатие до / после.

Я обычно использую rsync как rsync -abvz --partial....

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

Окружение: Исходный компьютер i7 для настольного компьютера с использованием жесткого диска SSD. Целевой компьютер Synology NAS DS413j с гигабитным сетевым подключением к исходному компьютеру.

Естественно, точная спецификация комплекта будет влиять на производительность, и я не знаю подробностей моей точной настройки качества сетевого оборудования на каждом конце.

Исходные файлы - моя папка ~ / .cache, которая содержит 1,2 ГБ в основном очень маленьких файлов.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Я сохранил 1a и 1b как отдельные шаги, чтобы проиллюстрировать задачу. Для практических применений я бы порекомендовал то, что Gilles опубликовал выше, касающееся передачи вывода tar через ssh в непересекающийся процесс на приемнике.

Тайминги:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

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

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

Ник

Использование rsync для отправки архива tar в соответствии с запросом на самом деле будет пустой тратой или ресурсами, поскольку вы добавите в процесс слой проверки. Rsync будет проверять контрольную сумму tar-файла на правильность, когда вы предпочитаете проверять отдельные файлы. (Не помогает знать, что tar-файл, который мог быть неисправен на отправляющей стороне, уже показывает тот же эффект на принимающей стороне). Если вы отправляете архив, ssh / scp - это все, что вам нужно.

Одна из причин, по которой вам, возможно, придется выбрать отправку архива, заключается в том, что по вашему выбору tar смог сохранить больше спецификаций файловой системы, таких как Access Control List или другие метаданные, часто хранящиеся в Extended Attributes (Solaris) или Ressource Forks (MacOS). ). При работе с такими вещами ваша главная задача будет заключаться в том, какие инструменты могут сохранять всю информацию, связанную с файлом в исходной файловой системе, при условии, что целевая файловая система также способна их отслеживать.

Когда скорость - ваша главная проблема, это сильно зависит от размера ваших файлов. В целом, множество мелких файлов будет плохо масштабироваться по сравнению с rsync или scp, поскольку все они будут тратить каждый отдельный сетевой пакет, где tar-файл будет включать несколько из них в загрузку данных одного сетевого пакета. Еще лучше, если файл tar будет сжат, поскольку небольшие файлы, скорее всего, будут сжаты лучше в целом, чем по отдельности. Насколько я знаю, и rsync, и scp не оптимизируются при отправке целых отдельных файлов, как при первоначальной передаче, так как каждый файл занимает весь фрейм данных со всеми издержками протокола (и тратит больше времени на проверку вперед и назад). Однако Янечекзаявляет, что это верно только для scp, отменив, что rsync оптимизировал бы сетевой трафик, но за счет построения огромных структур данных в памяти. Смотрите статью Эффективная передача файлов, Janecek 2006 . Так что, по его словам, все еще верно, что scp и rsync плохо масштабируются на маленьких файлах, но по совершенно другим причинам. Думаю, мне придется покопаться в источниках в эти выходные, чтобы узнать.

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

Постскриптум: В наши дни rdist, похоже, забывается, но до дней rsync это был очень эффективный инструмент, который широко использовался (безопасно при использовании через ssh, небезопасно в противном случае). Я бы не стал работать так же хорошо, как rsync, поскольку он не оптимизировал бы просто передачу измененного контента. Его основное отличие от rsync заключается в том, как он настроен и как прописаны правила обновления файлов.

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

Я не знаю точно внутренностей rsync. То, вызывает ли статистика файлов задержку, зависит от того, как rsyncданные передаются - если статистика файлов передается одна за другой, RTT может сделать tar + rsync + untar быстрее.

Но если у вас есть, скажем, 1 ГиБ данных, rsync будет работать намного быстрее, если только ваше соединение не будет очень быстрым!

Мне пришлось переместить несколько терабайт данных по всей стране, ровно один раз. В качестве эксперимента, я провел два из переводов с использованием rsyncи ssh/tarпосмотреть , как они соотносятся.

Результаты:

• rsync файлы передаются со средней скоростью 2,76 мегабайта в секунду.
• ssh/tar файлы передаются со средней скоростью 4,18 мегабайта в секунду.

Детали: Мои данные состоят из миллионов сжатых файлов .gz, средний размер которых составляет 10 мегабайт, но некоторые превышают гигабайт. Существует структура каталогов, но она меньше по размеру данных внутри файлов. Если бы у меня было почти что-нибудь еще, я бы только использовал, rsyncно в этом случае ssh/tarэто функциональное решение.

Моя работа с rsyncсостоит из:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

где fileList.txt - большой длинный список относительных имен файлов на другой стороне. (Я заметил, что --compressпосле того, как я запустил файл, он не является продуктивным для сжатых файлов, но я не собирался возвращаться назад.)

Я начал другой с ssh и tar, который имеет:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Вы будете наблюдать это все копии, извините, это не 100% сравнение яблок с яблоками.

Я должен добавить, что пока я использую внутреннюю сеть компании, мне нужно пройти через посредника, чтобы добраться до компьютера источника данных. Время эхо-запроса от моего целевого компьютера до посредника составляет 21 мс, а от посредника до источника данных - 26 мс. Это было одинаково для обоих переводов.

SSL-соединение через посредника осуществляется через ~/.ssh/configзапись:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Время это:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"