Hi,
Adam Goryachev wrote on 2009-07-09 12:07:11 +1000 [Re: [BackupPC-users]
suggestion: make wakeups start at 8am]:
> Holger Parplies wrote:
> > I don't think the name is important. It's an implementation detail. You can
> > change related config settings and the documentation without renaming the
> > binary. [...]
>
> The name only matters in that people may infer meaning where it is not
> meant. Though this could be fixed through documentation, and a few
> interface changes. For example, if the web interface config displayed
> the setting as DailyMaintenance instead of NightlyMaintenance even
> though the binary that uses the setting was Backuppc_nightly... If
> someone knows enough about backuppc to find the binary name, then they
> should also know enough (to find out) what it does and why.
that is what I meant. But I see that you might infer meaning where it is not
intended. You can find an instance of "BackupPC_nightly" in "ps" and wonder
why it's running in the middle of the day. Hmm.
> > Coincidentally, this maintenance task is not supposed to disturb backups ...
>
> Except it is pretty well acknowledged that it does due to the high
> amount of disk IO...
Sorry, I was unclear. I meant, this maintenance task should be run at a time
where it will not disturb backups, as opposed to other maintenance tasks that
should not disturb humans. So "nightly", from the perspective of a backup job,
is possibly during the day ;-). Or it should disturb neither backups nor
humans and be run in the morning.
There is no question that BackupPC_nightly will slow down backups (and
humans ...). Both running concurrently will almost certainly take longer
than both running sequentially (except perhaps for very slow links).
> > Agreed. The default should be good enough for most people - particularly
> > unexperienced users -, disruptive for nobody, and follow the principle of
> > least surprise. Early morning seems reasonable. Inside the blackout window
> > makes sense but may be surprising.
>
> Only in that a user may think the blackout period applies to all
> backuppc activity as opposed to backup hosts activity...
That is what I meant. "Hey, we're in the blackout period! Why is my disk going
crazy?" But whoever configured the blackout period (or just noticed there is
one) should have come across a reference to the maintenance job, and that
reference should have made clear that it is exempt from blackout.
> However, I agree that it should be scheduled to occur (by default) during the
> (default) blackout period.
I don't say I don't agree. Maybe the documentation/web interface should more
explicitly call it "backup blackout period" or something. Maybe it should even
be less definite than "blackout", since it's really only a hint that BackupPC
will ignore if necessary. It's really the opposite of a "preferred backup
window".
> > I'd argue for making BackupPC_nightly run time independent of
> > the WakeupSchedule. The WakeupSchedule defines possible times when backups
> > may be started (though they may continue or be started delayed due to
> > MaxBackups). Having an independent time for BackupPC_nightly where no
> > backups
> > are considered makes sense, eg.
> >
> > $Conf {WakeupSchedule} = [ 21, 22, 23, 0, 1, 2, 3 ];
> > $Conf {NightlySchedule} = [ 7.75 ];
>
> Not a bad idea, for example if I know all my hosts have a blackout time
> of 7am - 7pm, then why do I need backuppc to wake up and schedule all
> the hosts, only to find out that backups are not needed?
What's worse, it may decide that a backup *is* needed (because of unexpected
ping failures or something), although you never intended for one to be done at
that time.
It should be possible to define when backups are intended to be run
(WakeupSchedule), give preferences for when to run them (BlackoutPeriod) and
configure when to run the maintenance job(s). Maintenance jobs and backups are
really independent. In my opinion, using a common schedule is just saving a
configuration variable. If you want both backups and maintenance to run at
22:00, you can do that just as well with independent settings.
> Also keep in mind that unless you have a very small pool, and/or very
> fast (disks) pool, then your daily maintenance will probably take much
> more than 15 mins... (Mine takes around 3 hours).
I'm totally surprised to see times of 5 minutes on one pool and 23 on another.
I seemed to remember something like 2 hours, too. Well, I'm not complaining ;-).
> Well, we could hive off the pool maintenance into a new binary called
> backuppc_poolmaintenance and have that run separate from the
> backuppc_dailymaintenance which does the email, status.pl updates,
> etc...
That thought had occurred to me, too, at least for the e-mails. Don't the
status.pl updates (partly) reflect the results of traversing the pool?
> > I could imagine reasons to want a complete pool traversal on a particular
> > day rather than splitting it up equally. [...]
>
> True, and this could be done better if backuppc_poolmaintenance was a
> different process. In fact, again it would make it possible to disable
> pool maintenance within backuppc, and schedule it from cron to give a
> totally flexible schedule (ie, every wednesday in the first week of the
> month at 3am, or whatever)...
Yes ... good idea. But you'd have to do it via BackupPC_serverMesg (there
already is a command "BackupPC_nightly run" available) to get it synchronized
with BackupPC_link.
> I guess what we all should also recognise is that we don't do loads of
> work where none is really required.
Unless it's fun ;-).
> The simplest change (ie, change of default value, and changing the
> documentation) should be done, the rest of the suggestions being
> discussed are much more optional (IMHO).
I agree. Leaving this work to Craig is also optional. We should discuss this,
agree on some things, and then work out a patch (for the documentation and
config changes, no renaming binaries ;-).
Regards,
Holger
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
