On Mon, Sep 17, 2012 at 11:05 AM, Timothy J Massey <tmas...@obscorp.com> wrote:
>
>
> I'm writing a longer reply, but here's a quick in-thread reply:
>
> I know exactly what you mean by waiting until after the first full. Often
> the second full will be faster -- but only *IF* you are bandwidth limited
> will you will see an improvement. In this case, neither him nor I are
> bandwidth limited. I don't see an improvement.
The 2nd might even be slower, since the server side has to decompress
and recompute the checksums.
> I am routinely limited to no more than 30MB to 60MB per *minute* as the
> maximum performance for my rsync-based backups. This is *really* pretty
> terrible. I also see that the system is at 100% CPU usage when doing a
> backup. So, my guess is that the Perl-based rsync used by BackupPC is to
> blame.
I'd blame the CPU first. It's easier to replace with something faster...
> So, I have two CPU-bound tasks and they're both fighting over the same
> core.
>
> Is there anything that can be done about this?
Not sure about that - I always expected the kernel scheduler to do
something sensible, but maybe not.
> A quick aside about checksum caching: I very much *want* the ability to
> check to make sure if my backup data is corrupted *before* there is an
> issue, so I do not use checksum caching. So, yes, this puts much greater
> stress on disk I/O: both sides have to recalculate the checksums for each
> and every file. But the client can do it without monopolizing 100% of the
> CPU; the BackupPC side should be able to, too...
Backuppc is decompressing, and doing it all in perl, so I'd expect
that to be less efficient. However, there is a setting to control how
much of the data (a random percentage) is checksum-checked even with
caching enabled, so you can tune the timing vs. risk to some extent.
There's little risk of file-level corruption that would still let the
checksums cached at the end of the file match unless you have bad RAM
(which would likely cause crashes) or physical disk block corruption
which you can check relatively quickly with a 'cat /dev/sd?
>/dev/null' or a smartctl test run followed by checking the status.
--
Les Mikesell
lesmikes...@gmail.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
