[GRLUG] rsnapshot problem with compression
Michael Mol
mikemol at gmail.com
Wed Jun 16 21:30:09 UTC 2010
On Tue, Jun 15, 2010 at 10:36 AM, L. V. Lammert <lvl at omnitec.net> wrote:
> Trying to get compression working on one of our backup jobs, .. but it
> seems to be choking as soon as I add the --compress:
>
> /usr/local/bin/rsync -a --delete --numeric-ids --relative
> --delete-excluded \
> --compress --exclude=/dev/ --exclude=/mnt --exclude=/sys/ \
> --exclude=.gvfs/ --exclude=/lost+found/ --exclude=/media/ \
> --exclude=/proc/ --exclude=/tmp/ --exclude=/u/VM/ --exclude=.Trash* \
> --exclude=/u/Downloads/ --exclude=/u/VBoxBackup/ --rsh="/usr/bin/ssh
> ..
>
> received request to transfer non-regular file: 3286 [receiver]
> rsync error: protocol incompatibility (code 2) at rsync.c(336)
> [receiver=3.0.6]
> rsync: writefd_unbuffered failed to write 4 bytes to socket [generator]:
> Broken pipe (32)
> rsync error: error in rsync protocol data stream (code 12) at io.c(1525)
> [generator=3.0.6]
>
> According to docs, rsync is *supposed* to use standard compression a la
> zlib:
>
> "... include compression and decompression of data block by block
> using zlib at sending and receiving ends ..."
>
> HOWEVER, it appears that either this is not the case, or something has
> changed between different machines, as BOTH rsync's are the same:
>
> rsync version 3.0.6 protocol version 30
>
> If anyone can shed some light on the problem, it would be appreciated.
>
> Lee
I followed your earlier link, and came across mention that it's a
known bug/limitation in the zlib API, but that they hadn't implemented
a workaround yet.
--
:wq
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the grlug
mailing list