tar + rsync + untar. Какое-либо преимущество скорости просто rsync?

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

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

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

Одна причина Вам, возможно, придется выбрать отправку архива, состояла бы в том, если бы tar по Вашему выбору смог сохранить больше экстренного сообщения файловой системы, такого как Список управления доступом или другие Метаданные, часто хранившиеся в Расширенных Атрибутах (Солярис) или Ветвления Ressource (MacOS). При контакте с такими вещами основное беспокойство будет, относительно которого инструменты могут сохранить всю информацию, это связано с файлом в исходной файловой системе, обеспечивание целевой файловой системы имеет возможность отслеживать их также.

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

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

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

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

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

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

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

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

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

Исходные файлы являются моим ~/.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 отправил выше вовлечения pipeing вывод tar через ssh к не смолящему процессу на получателе.

Синхронизации:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

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

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

Nick

Время это:

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

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