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
|