Les Mikesell <firstname.lastname@example.org> wrote on 09/17/2012
> On Mon, Sep 17, 2012 at 7:59 AM, Mark Coetser <email@example.com>
> > Surely disk io would affect normal rsync as well? Normal rsync
> > nfs get normal transfer speeds its only rsync within backuppc
that is slow.
> Backuppc uses its own rsync implementation in perl on the server side
> so it will probably not match the native version's speed.
Sadly, I think this is where the problem lies.
> Is this the
> first or 2nd full run? On the first it will have to compress
> create the pool hash file links.
But doesn't this get done at the link stage, not the
backup stage? I didn't think that the "link running" part
even got counted in the backup time...
In my case, this is well after the first (or first
> On the 2nd it will read/uncompress
> everything for block-checksum verification. If you have enabled
> checksum caching, fulls after the 2nd will not have to read/uncompress
> unchanged files on the server side.
I'm going to have to test this... but I really
don't like the fact that with checksum caching a file corrupted on the
backup server will remain undetected--until the user tells me so when I
restore it... :(