gmail.com> writes:
>
> Or even (forgive me please rabid BackupPC devotees) consider another
> tool to handle those special-case files.
I've done a bit of investigation on this. I used rdiff, which is a command-line
interface to the algorithm used by both rsync and rdiff-backup. It looks like
On Wed, Feb 02, 2011 at 06:20:15PM +0100, martin f krafft wrote:
> also sprach Robin Lee Powell
> [2011.02.02.1757 +0100]:
> > There's a log for each client, which you can see by accessing
> > the client in the GUI (it'll be the top-most "LOG File" link)
> > and a log for the server as a whole.
>
also sprach Robin Lee Powell [2011.02.02.1757
+0100]:
> There's a log for each client, which you can see by accessing the
> client in the GUI (it'll be the top-most "LOG File" link) and a log
> for the server as a whole.
Oh, of course, sorry. But there is nothing in that log file hinting
at any
On Wed, Feb 2, 2011 at 10:58 PM, John Goerzen wrote:
> This *is* the smallest possible chunk, sadly ;-)
>
>> You may want to consider a separate backup profile of the database dumps. So
>> set up one backup for the rest of the machine; and another backup (using
>> $Conf{ClientNameAlias} to point t
On Wed, Feb 02, 2011 at 05:53:33PM +0100, martin f krafft wrote:
> also sprach Robin Lee Powell [2011.02.02.1720
> +0100]:
> > > 2011-02-02 15:00:00 Next wakeup is 2011-02-02 16:00:00
> > > 2011-02-02 16:00:00 Next wakeup is 2011-02-02 17:00:00
> > > 2011-02-02 17:00:00 Next wakeup is 2011-
also sprach Robin Lee Powell [2011.02.02.1720
+0100]:
> > 2011-02-02 15:00:00 Next wakeup is 2011-02-02 16:00:00
> > 2011-02-02 16:00:00 Next wakeup is 2011-02-02 17:00:00
> > 2011-02-02 17:00:00 Next wakeup is 2011-02-02 18:00:00
> > 2011-02-02 17:00:21 Started full backup on seamus.madd
Stephen Joyce physics.unc.edu> writes:
>
> Wouldn't it be easier to eliminate the problem? BackupPC is comparing the
> files to determine if they're identical (normally using lots of CPU to
> uncompress the pooled file, but since you're not using compression, that's
> not your issue).
>
> Wh
Wouldn't it be easier to eliminate the problem? BackupPC is comparing the
files to determine if they're identical (normally using lots of CPU to
uncompress the pooled file, but since you're not using compression, that's
not your issue).
Why not simply name your database dump differently each ti
On Wed, Feb 02, 2011 at 05:11:50PM +0100, martin f krafft wrote:
> also sprach Robin Lee Powell [2011.02.02.1704
> +0100]:
> > What does the host log say?
>
> Nothing, really:
>
> 2011-02-02 15:00:00 Next wakeup is 2011-02-02 16:00:00
> 2011-02-02 16:00:00 Next wakeup is 2011-02-02 17:00:00
Let me ask some more general questions: What does the background queue
actually *mean*?
What does a green background in the Host Summary mean?
All but one host (!), 226 out of 227, is in the background queue,
which seems rather excessive since about half my hosts have recent
backups.
All the h
also sprach Robin Lee Powell [2011.02.02.1704
+0100]:
> What does the host log say?
Nothing, really:
2011-02-02 15:00:00 Next wakeup is 2011-02-02 16:00:00
2011-02-02 16:00:00 Next wakeup is 2011-02-02 17:00:00
2011-02-02 17:00:00 Next wakeup is 2011-02-02 18:00:00
2011-02-02 17:00:21 S
On Wed, Feb 02, 2011 at 04:54:57PM +0100, martin f krafft wrote:
> also sprach Robin Lee Powell [2011.02.02.1628
> +0100]:
> > > What could be the reason for this?
> >
> > Most likely the disk is too full.
>
> Nope. The disk is at 67%. And if it were too full, I would have
> received an e-mail.
Carl Wilhelm Soderstrom real-time.com> writes:
> You may want to experiment with using tar instead of rsync for your backups.
> Tar is notably faster than rsync when you know you're going to grab a large
> percentage of changed files.
That's an interesting point. I will give tar a try. For mos
also sprach Robin Lee Powell [2011.02.02.1628
+0100]:
> > What could be the reason for this?
>
> Most likely the disk is too full.
Nope. The disk is at 67%. And if it were too full, I would have
received an e-mail.
--
martin | http://madduck.net/ | http://two.sentenc.es/
gentoo: the perform
On 02/02 03:12 , John Goerzen wrote:
> So I should add that additional testing shows that it was only the first full
> backup that was fast. Every subsequent backup, whether full or incremental,
> proceeded at the same very slow pace. rsync pegged at almost 100% CPU on the
> machine being backed
On Wed, Feb 02, 2011 at 04:07:41PM +0100, martin f krafft wrote:
> Hello,
>
> I have a BackupPC configured with FullPeriod at 7.97 and daily
> incremental backups, no blackout periods, hourly wakeup, and
> 2 consecutive backups permitted.
>
> One of the hosts' last full backup is now 8.2 days old
Hello,
I have a BackupPC configured with FullPeriod at 7.97 and daily
incremental backups, no blackout periods, hourly wakeup, and
2 consecutive backups permitted.
One of the hosts' last full backup is now 8.2 days old, while it's
incremental backup is 0.9 days old.
BackupPC just woke up, but it
John Goerzen complete.org> writes:
> I've been noticing something weird here. I backed up a machine here for
> the first time. The full backup took 28 minutes. The incrementals then
> took 602 minutes, and the next one 629 minutes. Very strange, eh?
So I should add that additional testing
Hi,
I've been noticing something weird here. I backed up a machine here for
the first time. The full backup took 28 minutes. The incrementals then
took 602 minutes, and the next one 629 minutes. Very strange, eh?
I'm not using compression in my pool (compression level is 0).
I discovered t
19 matches
Mail list logo
