Clint Alexander wrote:
>> That would be fairly hard to predict if you have more than a few machines
>> because it will be your concurrency limit that keeps backups from 
>> starting - and
>> you'd need to know how long the previous backups will take to know when 
>> the next
>> can start.
> 
> This is something that can be computed automagically by BackupPC to estimate 
> (albiet not exact).
> 
> 
>> You can see from the host summary page how long it has been since the last 
>> run,
>> so if you are on an approximately daily schedule you can tell when the 
>> next will
>> be considered and run if not blocked by the concurrency limit or the 
>> blackout
>> schedule.  If you need more precise scheduling, you can use a cron job 
>> using
>> BackupPC_serverMesg to start specific machines - but you'll also need to 
>> make
>> sure that there are not too many other jobs running at the time.
> 
> Right, I could follow a trend that would be based off of current 
> configuration -- but so could BackupPC.

Not really - your fulls will most likely take enough longer that it will skew 
the times the next set start, and your fulls are probably (and should be) 
running on different days for different machines.

> My issue really revolves around the 
> changing of the configuration in which it should tell (based on previous 
> thesholds, run times, # of files, etc) an approximate date/time.
> 
> Even if the BackupPC reads: "With the current configuration, BackupPC will 
> attempt to backup the server @ yyyy-mm-dd hh:mm. This can be affected by # 
> of concurrent, <other limitations and factors>..."

The scheduler will never start a run sooner than the time you set to elapse 
between runs - and you can see how much time has elapsed from the host summary 
page.  I suppose it could factor in the blackout schedule and show the next 
possible time one could start, but once your schedule settles down it should be 
rare for a 24 hour cycle to collide with blackouts and you should expect 
something to start when the time hits a day unless it is limited by concurrency 
(which you can estimate by the other hosts that will hit a day at the same time 
or slightly sooner).

> If it's a matter of any mathmatical computation -- BackupPC can do this 
> automatically with the understanding that it is an estimate based on 
> previous tends (if any).
> 
> Right?

Estimating from previous trends isn't going to help you much when you are 
making 
changes.   What I usually do is manually force a run at approximately the time 
I'd like the scheduler to run them subsequently and let the 24 hour timing take 
it from there  (otherwise you can't advance the required elapsed time between 
runs).  But if you really need to hit a small window with competition from 
other 
runs, a cron job is the best approach.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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/