There is one suggestion I would add to this discussion. If you are going to
run a script to change the retention level, I think it would be better to
set the default to the 7 years and change the non quarterly to a lesser
retention level. This way if a script fails and no one notices, you have 7
years to fix it.
Just my £.02 worth.
Regards,
Patrick Whelan
Whelan Consulting Limited
VERITAS Certified NetBackup Support Engineer for UNIX.
VERITAS Certified NetBackup Support Engineer for Microsoft Windows.
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Curtis
Preston
Sent: 31 March 2008 22:49
To: Ed Wilts; Wayne T Smith
Cc: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Quarterly Backups and Calendar Schedule
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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
