Имеет ли опция сжатия -z с rsync ускорить резервное копирование

В rsync, -z будет сжимать данные файла во время передачи.

Если я правильно понял, -z сжимать файлы перед передачей, а затем распаковывать их после передачи. Уменьшается ли время во время переноса из-за сжатия в сжатом времени времени для сжатия и декомпрессии?

Отвечает ли ответ на вопрос, если я делаю резервное копирование на внешний hdd через usb (2.0 или 3.0) или на сервер ssh через Интернет?

27 голосов | спросил Tim 7 MaramSat, 07 Mar 2015 11:51:23 +03002015-03-07T11:51:23+03:0011 2015, 11:51:23

5 ответов


30

Это общий вопрос. Уменьшает ли сжатие и декомпрессию на конечных точках эффективную пропускную способность канала?

Эффективная (воспринимаемая) полоса пропускания связи, выполняющей сжатие и декомпрессию на конечных точках, является функцией:

  1. , как быстро вы можете сжимать (скорость вашего процессора)
  2. фактическая пропускная способность вашей сети

Функция описывается с помощью этого трехмерного графика, который вы можете запросить для конкретной ситуации:

 введите описание изображения здесь>> </a> </p>

<p> График исходит из <a href= Компрессионные инструменты по сравнению в статье 2005 года http://www.linuxjournal.com/.

ответил PSkocik 25 J0000006Europe/Moscow 2016, 10:07:55
11

Если у вас очень медленное соединение (думаю, GPRS), вы определенно хотите сжать ваши данные как можно больше, иначе ваше соединение замедлит работу.

Если у вас очень медленный процессор и быстрое соединение (например, встроенное сетевое устройство), вы обычно не хотите сжимать свои данные, иначе ваш процессор замедлит работу.

ответил michas 7 MarpmSat, 07 Mar 2015 12:19:00 +03002015-03-07T12:19:00+03:0012 2015, 12:19:00
2

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

Сжатие помогает только тогда, когда у вас есть отправитель и ресивер rsync и какая-то более медленная сеть между ними. 1Gbit может быть уже достаточно быстрым, когда у вас есть локальный NAS, например, 10Gbit уже является сырой скоростью SATA. Поэтому сжатие требуется только тогда, когда у вас есть 100 Мбит или меньше возможностей подключения, и это имеет смысл только тогда, когда сжатые данные сжимаются.

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

ответил René Schwietzke 7 MarpmSat, 07 Mar 2015 12:16:29 +03002015-03-07T12:16:29+03:0012 2015, 12:16:29
2

Зависит от того, насколько сжимаемыми являются ваши данные и вычислительная мощность вашего источника и места назначения. Полная резервная копия диска по моему опыту будет сжиматься примерно до 30-50% от его первоначального размера, поэтому может быть стоит сделать снимок. В противном случае не беспокойтесь о сжатии. Возможно, стоит проверить степень сжатия с помощью pigz -c <your file> | wc -c и сравнить возвращаемый размер с исходным размером.

ответил RAKK 7 MarpmSat, 07 Mar 2015 22:15:53 +03002015-03-07T22:15:53+03:0010 2015, 22:15:53
1

tl; dr По медленным каналам передачи, сжимайте, иначе нет. Ниже приведен тест скорости сжатия, ссылка на инструмент преобразования полосы пропускания и некоторая информация.

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

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

Ниже приведен очень ненаучный тест, который покажет, как быстро gzip может создавать данные, и что это значит для вас сжимайте сетевые массовые переводы в целом.

Входные данные значительно изменят результат теста . Я использую несжатый (!) Обычный файл на моем компьютере, который может представлять собой тип данных, которые я обычно передаю по сетям. Использование /dev/zero (создание неограниченных нулей) будет вводить в заблуждение, поскольку поток нулей будет очень легко сжиматься и с помощью /dev/random будет вводить в заблуждение по другой причине. Поэтому вместо этого я использую tar-файл моего каталога $HOME/local, который содержит программное обеспечение, которое я установил в своем $HOME. Файл несжатый сам по себе, но содержит сочетание двоичных файлов, небольших сжатых файлов и исходных /текстовых файлов, и я бы сжимал его по умолчанию для gzip, он уменьшится на 67% с 64 MiB до 22 MiB.

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

Я делаю это несколько раз, чтобы понять, что может быть в среднем, и оно составляет около 7800000 байт /с.

Затем я использую калькулятор пропускной способности сети , чтобы увидеть, в чем он преобразуется. В этом конкретном случае он, как оказалось, находится под пропускной способностью проводной связи «100 Мбит Ethernet», что намного быстрее, чем «восходящая» интернет-связь «VDSL Download», немного быстрее, чем беспроводная связь «802.11 [a /g]» и где-то между «Bluetooth v3.0» (медленнее) и «USB 2.0» (быстрее).

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

rsync может не использовать точные те же библиотеки, что и gzip, чтобы выполнить сжатие, но приведенное выше даст вам хоть немного намека.

rsync делает больше, чем сжатие, хотя, как вы знаете, и увеличение скорости real происходит только от перенос [бит] файлов, которые были изменены.

В моем собственном опыте использование сжатия с помощью rsync стало менее привлекательным в течение последних 10 лет или около того, поскольку пропускная способность сетей увеличилось (где я).

Для создания инкрементных резервных копий я определенно рекомендую изучить параметр --link-dest (это не имеет ничего общего с переданным, только с тем, как вещи хранятся у цели). Кроме того, если вы делаете это через SSH, не используйте сжатие, если ваше соединение SSH уже сжато и только сжимает SSH-соединения (туннели и т. Д.), Которые находятся по медленным ссылкам, по тем же причинам, что и выше.

ответил Kusalananda 25 J0000006Europe/Moscow 2016, 09:32:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132