Делает опцию сжатия-z с rsync, ускоряют резервное копирование

Зависит от того, насколько сжимаемыми являются ваши данные и мощность обработки вашего источника и назначения. Полное резервное копирование диска в моем опыте будет сожмите примерно до 30-50% своего первоначального размера, поэтому возможно, стоит дать ему выстрел. В противном случае не беспокойтесь с компрессией. Может быть, стоит проверить вашу скорость сжатия с PIGZ -C <ваш файл> | WC -C и сравните возвращенный размер с вашим оригинальным размером.

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

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

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

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

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

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

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

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

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

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

$ 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 делает больше, чем просто сжатие, как вы знаете, и реальное увеличение скорости происходит за счет передачи только [битов] измененных файлов.

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

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

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

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

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

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

График основан на статье Сравнение средств сжатия 2005 г. http://www.linuxjournal.com/ .

Я рекомендую использовать --compress --compress-choice=lz4. lz4 имеет скорость сжатия более 500 МБ/с с довольно хорошим коэффициентом сжатия, поэтому он не будет вызывать каких-либо накладных расходов даже на очень быстрых сетевых соединениях, при этом получая большое преимущество для сжимаемых файлов.

Единственным недостатком является то, что он работает только с новыми версиями rsync, а не с Debian oldstable.

Как правило, вы можете определить, когда сжатие является узким местом, по процессу rsync на стороне отправителя, использующему 100% процессорного времени.