20

Rsync has command line arguments for compression:

-z, --compress              compress file data during the transfer
    --compress-level=NUM    explicitly set compression level

What does --compress-level mean? Which numbers can be used as level?

cronfy
  • 711

4 Answers4

21

It's values between 0-9. Where 1 is fastest and 9 is the most compressed. Other than that there's correlation between rsync and zlib where rsync tells the zlib library to "use the default compression". In zlib's docs, it says this:

Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6).

Gabriel Staples
  • 285
Michal
  • 434
6

rsync since version 3.2.0 supports more than zlib:

--compress, -z
       turn on compression
--compress-choice=STR, --zc=STR
       choose compression from lz4 (fastest), zstd, zlibx, zlib (slowest), none
--compress-level=NUM, --zl=NUM
       zlib and zstd can be tuned with compression level
       zlib from 1 (lowest) to 9 (highest), default 6
       zstd from -131072 to 22, default 3
trumank
  • 103
ptman
  • 29,862
4

Note that the local rsync documentation covers the information about --compress-level.

To find it:

  1. run man rsync
  2. type /compress-level (note the slash) and press ENTER
  3. type / and ENTER (repeat until satisfied)
  4. gotcha!
       --compress-level=NUM
              Explicitly set the compression level to use (see --compress) in‐
              stead of letting it default.  Allowed values for NUM are between
              0 and 9; default when --compress option is specified is  6.   If
              NUM is non-zero, the --compress option is implied.

Having said that, I admit it's not very explanatory about the actual behavior of NUM... but bigger NUM means more compression. So:

rsync --compress-level=9

That enables maximum compression (so, maximum CPU usage).

Note: very high compression levels are useful for very limited connection bandwidth. On high-speed networks, this compression just slow down everything, since your CPU is busy in compressing instead of just copying.

Valerio Bozz
  • 394
3

The environment used was composed by two docker containers used with MACVLAN + some noise traffic (which gives around ±1% error) The fileX - in my case - is a binary one

So, below are the result of rsync tarred files versus rsync with compression (option -z) untarred files

      1. File tarred + rsync without compression (rsync -axvPAH fileX.tar destination:/path)

    File size is 56933 bits (fileX.tar)
    Transfer difference is 4735665-4673346=62319 bits

      2. File tarred + rsync with default compression (rsync -axvPAH -z fileX destination:/path)

    File size is 56933 (fileX.tar)
    Transfer difference is 4933845-4871608=62237

      3. File tarred + rsync with maximum compression (rsync -axvPAH -z --compress-level=9 fileX.tar destination:/path)

    File size is 56933 bits (fileX.tar)
    Transfer difference is 4870664-4808387=62277

      4. File untarred + rsync with default compression (rsync -axvPAH -z fileX destination:/path)

    File size is 237525 bits (fileX)
    Transfer difference is 4669946-4607637=62309 bits

      5. File untarred + rsync with maximum compression (rsync -axvPAH -z --compress-level=9 fileX destination:/path)

    File size is 237525 bits (fileX)
    Transfer difference is 4806735-4744764=61971 bits

      6. File untarred + rsync without compression (makes no sense since it’s the most bandwidth consuming one)
Zatarra
  • 415