Compressing unencrypted metafiles
throughnothing at gmail.com
Mon Feb 1 14:14:36 UTC 2010
This sound pretty good. As someone who pretty much only uses
encrypted backups, I do think it would be nice to make it optional to
not need the extra dependency, but it isn't a hug deal either way I
On Monday, February 1, 2010, Gavin Carr <gavin at openfusion.com.au> wrote:
> On one of my backups - unencrypted, lots and lots of small files, over a
> high latency link - the storage of the metafile takes 20 minutes, which is
> up to 2/3 of the time of the whole backup. Gzipping the metafile reduces
> that to 3 minutes, and reduces the storage requirements on both the client
> and the server from 30M to 5M.
> Reasonably straightforward patch attached. This only compresses for
> unencrypted backups, since we already get compression for free with
> encrypted ones.
> We should also implement compression of chunks for unencrypted backups at
> some point. But this remains a useful halfway-house, I think, because for
> some kinds of backups - like images, or music - chunk compression isn't
> going to buy you much, but metafile compression still makes sense.
> - I've made this the default behaviour for unencrypted backups - is that
> reasonable? Do we need a flag to be able to turn this off?
> - this adds another dependency, on IO::Compress. Is that ok? Should it be
> optional, so people who only do encrypted ones don't need to worry about
More information about the brackup