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

Вы не можете "сжать все целиком", так как gzip сжимает только один файл, вы можете создать tar-файл и скопировать его, чтобы "сжать все целиком", но вы потеряете возможность rsync копировать только измененный файл.

Поэтому вопрос в том, лучше ли хранить файл, который мне нужен, для использования rsync gziped или использовать опцию -z команды rsync.
Ответ, вероятно, заключается в том, что вы не хотите, чтобы файл был разархивирован на вашем сервере? Я думаю, да, так что я не понимаю, как вы могли бы сжать файл gzip перед выполнением rsync.

Может быть, вам не нужна возможность rsync копировать только измененный файл? В этом случае зачем использовать rsync вместо scp файла tar.gz, содержащего ваши материалы?

В любом случае, чтобы ответить на вопрос, rsync gzip будет немного менее эффективным, чем файл gziping с gzip. Зачем? поскольку rsync будет разбивать данные по частям gzip, поэтому для создания таблицы, которую gzip использует для сжатия, будет использоваться меньший набор данных, а больший набор данных (gzip будет использовать весь файл сразу) дает лучшую таблицу сжатия. Но в большинстве случаев разница будет очень очень мала, но в очень редком случае разница может быть более важной (если у вас очень большой файл с очень длинным партером, многократно повторяющимся в файле, но далеко друг от друга) (это очень упрощенный пример)

@radius, мелкая гнида о том, как gzip работает - gzip это алгоритм сжатия на основе блоков, причем довольно простой. Весь файл не рассматривается для таблицы сжатия - только каждый блок. Другие алгоритмы могут использовать все содержимое файла, и есть несколько, которые используют содержимое нескольких блоков или даже блоков переменного размера. Один увлекательный пример lrzipтем же автором, что и rsync!

Тощий наgzip Алгоритм

Итак, в итоге, используяrsync -z скорее всего, даст такое же сжатие, какgzipсначала - и если вы делаете дифференциальную передачу, лучше из-заrsyncОтличный алгоритм.

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

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

Если ваши диски являются узким местом, то лучше всего потоковую передачу в сжатый файл. (например, netcat с одной машины на другую, потоковое в gzip -c)

Обычно, если скорость является ключевым фактором, сжатие существующего файла заранее неэффективно.

TIMTOWTDI, YMMV, IANAL и др.

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

tar -cz /home/me/source/directory | ssh target tar -xz --directory /home/you/target/directory

Это позволит получить сжатие, которое вы ищете, и просто скопировать напрямую, без использования rsync.

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

Со страницы руководства:

          Note  that  this  option  typically  achieves better compression
          ratios than can be achieved by using a compressing remote  shell
          or  a  compressing  transport  because it takes advantage of the
          implicit information in the matching data blocks  that  are  not
          explicitly sent over the connection.

Поскольку и для scp сжатого файла, и для rsync потребуется очень похожее время передачи, "наиболее эффективным способом сделать это" будет сжатие на лету, а не сжатие, передача.

Помимо "быстроты" другие соображения включают в себя:

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

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

локальный tar или gzip требует локального пространства.

Рекомендации по использованию порта для целевой машины и брандмауэров: 1) scp использует порт 22 (по умолчанию), что может быть неприемлемо. 2) rsync для пользователей порт 873 (по умолчанию)

Я не уверен, почему радиус ожидает, что оригинальный постер НЕ хочет, чтобы файлы были разархивированы.