19

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
  • 671
  • 1
  • 6
  • 14

4 Answers4

20

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).

Michal
  • 424
  • 3
  • 7
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 Bozzolan
  • 279
  • 2
  • 10
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
  • 407
  • 3
  • 5
  • Useful data. Would be even better if it included total time (tarring plus rsync) so an analysis on time could also be done, since almost all options you listed are about the same bandwith expenditure – WurmD Apr 28 '20 at 09:52
2

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, --lz=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
ptman
  • 27,124
  • 2
  • 26
  • 45