tar + rsync + untar. Любое преимущество по скорости только за rsync?

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

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

tar + rsync + untar 

Или просто

  tar (from src to dest) + untar 

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

 rsync 

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

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

Обновить

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

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

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

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

Tip2: Если вы используете 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 сегодня и столкнулся с этим обсуждением, подумал, что добавлю свои результаты. Короче говоря, tar'ing по сети к целевой файловой системе быстрее в моей среде, чем rsyncing для одного и того же адресата.

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

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

Исходными файлами являются моя папка ~ / .cache, которая содержит 1.2Gb в основном очень маленьких файлов.

 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 опубликовал выше, используя вывод taring tar через ssh для процесса разборки на приемнике.

Тайминги:

 1a - 33 seconds 1b - 1 minutes 48 seconds 2 - 22 minutes 

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

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

Ник

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

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

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

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

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

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

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

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

Время:

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