What is more efficient / faster, rsync compression or ssh compression?

Question

I currently rsync files: (i) locally and (ii) remotely over WAN (connection c. 8mbps down / 1.5mbps up).

I am considering adding to rsync:

-z

to compress files.

Or alternatively adding to ssh:

-C

Which one is better and in fact, is there any large benefit at all?

Solution 1

Based off the rsync manual, it is better to compress with 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.

Solution 2

In most cases, rsync -z compression will suit your need. However, the rsync -z compression does not compress metadata exchanged prior to the file copy (notably files list). In order to also compress the files list, I would recommend to also use the ssh -C option. Especially when you have both:

• a large number of files to transfer
• few changes between your source and destination files

Comments

[Guest]

Thank you. If I'm compressing in rsync do I need to switch off ssh compression, so "-o Compression=no"? Or can I leave ssh as is?

[Darren]

Yes, turn ssh compression off. The data is already compressed, no need to try to compress it again.

[DrYak]

- Regarding SSH compression : Lots of people (and I really mean a lot) tend to put Comprssion yes in their .ssh/config files to improve data rate on slower links (when remoting over DSL or 3/4G, etc.) -oCompression=no is necessary in those configurations. - Regarding encryption : Blowfish is another possible (use: -c blowfish-cbc). It's theoretically weaker than AES256. But unlike RC4 it still hasn't known cryptanalytic weakness (though nowaday, nobody is actively looking at it) and is much faster on architectures lacking AES256 hardware acceleration.