Les Mikesell <lesmikesell@gmail.com> wrote on 09/17/2012 11:01:25 AM:

> On Mon, Sep 17, 2012 at 7:59 AM, Mark Coetser <mark@tux-edo.co.za> wrote:
> > Surely disk io would affect normal rsync as well? Normal rsync and even
> > 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 and
> 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 100) backups...

>  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...  :(

Timothy J. Massey

Out of the Box Solutions, Inc.
Creative IT Solutions Made Simple!

      22108 Harper Ave.
St. Clair Shores, MI 48080
Office: (800)750-4OBS (4627)
Cell: (586)945-8796