Ed, I'm going to agree and disagree with you here.

> The fact that we're saying that the jobs should run 
> on the last Friday of the quarter also tells me that you're not after
> quarterly backups or you'd run them 
> on the last day of the quarter, not the day that happens to be 
> conveniently around the end of the quarter 
> - you're not getting your quarter-end processing in this backup.

I'd agree here.  I'm guessing that he's not going after quarter-end processing, 
or he'd be trying the first Friday in the quarter, not the last.  I also agree 
with your earlier post that Randy needs to re-think his requirements.  I would 
question what this quarterly back up is for.  If we could better understand why 
he's doing it, perhaps we could suggest a different way to meet the 
requirement.  Based on his response to Jonathan's response, I'm guessing he's 
using it as a long-term archive (which anyone who knows me knows I don't like 
THAT idea).  If that's the case, then I see his dilemma, as NBU doesn't make 
this easy.  A 7 year old backup is a 7 year old backup.  It's not an archive, 
and 7 years from now when you're trying to use that 7 year old backup as an 
archive and trying to retrieve something from it (you retrieve from archives.  
You restore from backups), you'll know what I meant.  You'll rue the day you 
decided to keep a backup for 7 years.  That's all I'm going to say about that.

> What you've gone and done is set up a very complicated method of defining 
> a quarterly schedule that has a 90-day frequency and a schedule that 
> probably runs from Friday to Sunday.  

Although what Wayne proposed does sound a little convoluted, Schedule-based 
backups (SBB) would give Randy more than you describe.  They're a way to have a 
backup that runs every 90 days or so THAT PREDICTABLY RUNS ON THE SAME DAY 
every quarter and can be created today without a problem.  If he uses Frequency 
Based Backups (FBB), the first thing is he can't set it up now.  He has to wait 
until after the second to the last Friday and THEN add it, or it will run the 
next Friday it sees.  (Actually, it will run the next day there is a Window, 
which will probably be next Friday.)  In addition, if an FBB ever fails to run 
one Friday, it will run the next Friday, and then cause ALL FUTURE BACKUPS to 
be shifted out one week.  They will then shift another week the next time it 
happens, and so on.  He will need to monitor for this and run a manual backup 
to straighten it out.

I know FBB backups are simpler to understand and configure, but they are more 
difficult to CONTROL.  I therefore prefer SBB for anything other than daily 
backups.  (I don't like the behavior of SBB with daily backups, so I used FBBs 
for daily backups and SBBs for weekly and monthly backups.  I've never tried to 
use them for quarterly backups, but they weren't designed to do that.)

> The fact that you're allowing a failed/missed backup to run the following 
> Friday already tells me you don't 
> *need* a quarterly - you need a backup of roughly that frequency (and 
> probably retention).  If you absolutely had to have a quarterly backup, 
> you'd be retrying immediately and making it work.

OR it means that he doesn't have enough resources to do full backups on Monday. 
 The fewer resources he has, the more I would push for SBB, as they make 
spreading out the load caused by full and cumulative backups much easier.  I 
actually like to use them to spread out the load from fulls all across the 
month, with each night having 1/28th of the total load.

> Simple is good - too many manual steps and it the process will break down  
> - either by you when you get busy and forget the complicated retry steps, 
> or by your successor.

On this we are in agreement.  That's why I prefer Jonathan's answer.  Write a 
script that changes the retention of one backup each month to 7 years and run 
it once a quarter.  Either run it via a Windows schedule task (Randy said he's 
a Windows guy) or run it as a bpend_notify that runs after every monthly full.  
If it's a quarterly month, then change the retention.

> The scheduler doesn't need quarterly or yearly backups because 
> the functionality is already there.  

No it's not.  I've had customers that would like to do one year retention on 
their fulls, and to only do them once a quarter - and they want to use SBBs for 
the reasons I stated above.  The requirement is there and the functionality is 
not.

> The first rule of solving a problem is clearly defining the business
> problem you're trying to solve.  
> With all this complicated rule-set around a theoretical quarter-end 
> backup, what business problem have you solved?

On this we are in agreement, except that if my guess of his business 
requirement is correct, both FBB or SBB are a lousy way to meet electronic 
discovery requirements.  That's what archiving software is for.

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu