On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston <
cpreston AT glasshouse DOT com> wrote:
Ed, I'm going to agree and disagree with you here.
Fair enough, so long as you'll let me point out an incorrect claim in your argument too :-)
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.)
Actually, you're wrong here. NetBackup allows you to create a policy now but not set it to go active until some point in the future. I've used this and it works well.
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.
But if all he really wants is a backup that runs roughly every quarter, this does actually fill that need. Yes, they'll drift over time. It will also help balance the load across the policies so you don't get *all* of your quarterlies on the same day, decreasing the odds that you'll run out of backup window. More than likely, you'd like to spread the load across multiple Fridays unless you have a lot of backup window compared to the volume of backup. When you are responsible for hundreds of terabytes like I am, asking for everything to be backed up in a single weekend just gets you laughed at (or you can approve the requisition for a *lot* more hardware).
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.
The larger the environment, the important FBB is. Yes, they're more difficult to control, but that's also an advantage - you don't *want* to have to control them. The more control you take, the less NetBackup has, and the more likely it is that backups won't run.
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.
And I don't prefer Jonathan's answer for that reason. Sometime in the future, somebody will rebuild that box and could forget all about scheduled tasks and the script won't run. He'll either run out of tapes because images weren't expiring soon enough (or slowly spend a lot of money on tapes that he doesn't to), or he'll not extend the quarterly to a 7-year expiration and end up expiring images he's not supposed to. And then he won't notice until he gets audited or needs to do a restore.
The problem with this approach is that it can die silently - the script may not run somebody and unless you have some other external way of validating that it ran, it can be easily missed. I'm a bit anal about solutions that can die silently - they tend to make me hostile.
If you do go this route, you *must* write a script on a different system that validates those backups and makes sure the retentions are what they're supposed to be.
