On Wed, 2020-03-25 at 19:15 +0100, Simon Matter via CentOS wrote: > > On Wed, 2020-03-25 at 14:39 +0000, Leroy Tennison wrote: > > > Since you state that using -z is almost always a bad idea, could you > > > provide the rationale for that? I must be missing something. > > > > > I think the "rationale" is that at some point the > > compression/decompression takes longer than the time reduction from > > sending a compressed file. It depends on the relative speeds of the > > machines and the network. > > > > You have most to gain from compressing large files, but if they are > > already compressed, then you have nothing to gain from just doing small > > files. > > > > It obviously depends on your network speed and if you have a metered > > connection, but does anyone really have such an ancient network > > connection still these days - I mean if you have fast enough machines > > at both ends to do rapid compression/decompression, it seems unlikely > > that you will have a damp piece of string connecting them. > > I really don't understand the discussion here. What is wrong with using -z > with rsync? We're using rsync with -z for backups and just don't want to > waste bandwidth for nothing. We have better use for our bandwidth and it > makes quite a difference when backing up terabytes of data. I don't really care if you use -z, but you asked for the rationale, and I gave you it. I'm not telling you what you should do. I'll try and make it simpler - if rsync takes 1 second to compress the file, then 1 second to decompress the file, and the whole transfer of the file takes 11 seconds uncompressed vs 10 seconds compressed, then dealing with file takes overall 12 seconds compressed, vs 11 seconds uncompressed. It's not worth it. But as I said it depends on your network and your machine speeds. It's up to you to decide what is best in your own situation. P.