Not necessarilly. :-)

We can calculate the time to start our job based on the end time of the
last job, while still using the start time of the last job for
calculating which files to backup. And the SysAdmin Manual for Unix, Vol
1, Page 108 says:

"Using the Frequency schedule type, administrators specify how much time
must elapse between the successful completion of a scheduled task and
the next attempt at the task."

Bob, I was very interested in you comments about the magical Interval
based backups, and Steve, I believe your tests - but how did you guys
find out about this? Is it documented somewhere?

Thanks,
        Tristan
 
---
Tristan Ball
System Administrator
Vision Systems
+61-3-9211-7064
 

-----Original Message-----
From: Ed Wilts [mailto:ewilts AT ewilts DOT org] 
Sent: Friday, 19 May 2006 2:34 AM
To: Bob Stump
Cc: Steve; Tim Wilkinson; veritas-bu AT mailman.eng.auburn DOT edu; Tristan
Ball
Subject: Re: [Veritas-bu] 'Frequency' schedule type

On Thu, May 18, 2006 at 09:39:09AM -0400, Bob Stump wrote:
> bpimagelist returns with the "start time" of the image.  The image 
> name contains the ctime of the start of the image.  Because of these 
> reasons, I believe that "Freq is measured when the backup STARTS if 
> you are using Freq based scheduling." But I have no proof and I have 
> read conflicting posts from users using different versions of 
> Netbackup.

I believe I've done the calculations before for the VMS client - the
relevant data is logged - and the date used is measured from when the
last backup STARTS, not ENDS.  If you think about it, it *has* to be
this way or you will miss files.

eg. differential starts at 12:00 and ends at 18:00.  A file is created
at 16:00 but the directory it is in was processed at 13:00.  If you
started your next differential and selected all files since 18:00, you'd
skip the file and this would be bad.  If you start your next backup and
selected the files created since 12:00, you'd be okay.  Now of course
you could select the same file twice (e.g. if the file was created at
12:05 and the directory was processed at 13:00)) but that's a far better
problem than not backing it up at all.

--
Ed Wilts, Mounds View, MN, USA
mailto:ewilts AT ewilts DOT org