I am using rsync to back up a repository that contains many gz files including many new ones each day. The rsync backup proceeds more slowly than it should because these gz files are not built with gzip's --rsyncable option (which makes gz files much more 'rsync-friendly' without significantly increasing their size or affecting their compatibility). And I can't fix the problem at creation time because the files are generated by a python script (rdiff-backup) which uses python's gzip module and this does not support an equivalent to gzip's --rsyncable.
So before running rsync I can identify any new gz files in the source data (i.e. new since the last time rsync was run). Now I want to 're-gzip' these files so that they are gzipped in rsyncable-format. Then I can run rsync from the optimised source.
I think this means running each file through gunzip and then gzip --rsyncable but I am not too sure how to do this in a way that won't risk losing data or metadata. Suggestions gratefully received.
--rsyncable
should matter is if the files get changed between runs andrsync
tries to send the changes. New files don't care if they're rsyncable or not, becausersync
has to send all the data anyway. Are the files being changed between rsync runs?--rsyncable
.-a
flag. Also, my version of gzip doesn't have an--rsyncable
flag, but it does come with a program calledznew
that could probably be used for what you need.--rsyncable
wouldn't help. I was hoping for a line of code or short script that would safely unpack a gz archive and repack it using--rsyncable
. But it's just an academic question for me now.