Compressed backup

Dave Dykstra dwd at bell-labs.com
Thu May 30 13:49:02 EST 2002


On Thu, May 23, 2002 at 04:03:56PM -0400, David Bolen wrote:
> Matthias Munnich [munnich at atmos.ucla.edu] writes:
> 
> > No! Only the sender side has to compress the data. The comparison
> > could be done in the compressed data format. With the -z option 
> > the sender compresses the data anyway. The checksum test should
> > be faster for the smaller compressed pieces.
> 
> Except that you'll probably end up retransmitting the whole thing due
> to the change in compressed output.  Since a compression function is
> essentially a data randomizer (the better the compression the better
> the randomization of the output), tiny changes in input can result in
> huge changes in output.  That's the traditional problem of trying to
> use an algorithm like rsync's with compressed file formats.
> 
> You really need to apply the rsync algorithm to the uncompressed files
> if you hope to gain any real efficiencies in terms of reduction of
> traffic transmitted.

There is a patch available to gzip to add an option --rsyncable that's
supposed to make it work better with rsync.  It's been put into the
"patches" directory for the next release of rsync, or you can get it at

    http://rsync.samba.org/ftp/unpacked/rsync/patches/gzip-rsyncable.diff

- Dave Dykstra




More information about the rsync mailing list