Veritas-bu

Re: [Veritas-bu] How to plan out policy(schedules), [...]

2008-12-12 19:24:14
Subject: Re: [Veritas-bu] How to plan out policy(schedules), [...]
From: "Andrew White" <adwhite AT inchix DOT net>
To: veritas-bu AT mailman.eng.auburn DOT edu
Date: Sat, 13 Dec 2008 11:13:06 +1100


On Sat, Dec 13, 2008 at 10:31 AM, Curtis Preston <cpreston AT glasshouse DOT com> wrote:

Suit!?!?!  Them's fightin' words! 

 

I need to do a blog on this, as I answer this question a lot.

 

If you want to do weekly backups using frequency based schedules, here are your choices.

 

  1. Leave the window open only on the night you want the backup to run.  Schedules that succeed that night will be fine.  BUT if it fails that night, it won't retry until next week. Yuck.
  2. Leave all nights' windows open.  When the backup that's supposed to run Monday fails and then runs on Tuesday, it will always run on Tuesday from then on because that will be when it meets the frequency of 7 days.  Full backups end up creeping around and bunching together.  I HATE this one as it's unpredictable over time.  I've seen it where over time all my full backups were running on the same night.  (I like to spread them out.)
  3. Leave a few days' windows open (say, 3), and set a frequency of 4 days. This causes NBU to try on the first day with an open window, then retry on the second/third if it fails.  You have the retry feature that calendar-based backups have without the schedule creep problem because you have a frequency of four days.  (This is the best of the three, IMHO.)

  

The schedule-creep problem is compounded by manual backups.  If you ever do a manual backup, the frequency will be calculated from that day.  Suppose you chose option three above and opened the windows for Friday, Saturday, and Sunday night, and put a frequency of four days.  If you happened to run a manual full backup on Thursday night, your regular full backup won't run that weekend.

 

I agree 100% with Curtis on this.  If you have a large environment with drives/resources being super utilised schedule creep can and is  disastrous. 

Not to mention client X expected his full to run on day Y and needed to backout from a change based on the full backup - woops!

_I_ like to do monthly full backups and weekly cumulative incremental backups.  The above problems are compounded when you want to do this.  You can't reliably predict what night the fulls are going to run, and can't easily spread them out across the month (which I like to do).  It's much easier to spread them out using calendar based schedules.  You take some clients and tell them to do their full on the 1st Friday of the month, and their cumulative incremental every Friday.  When the two "clash" on the 1st Friday, the full takes precedence and runs.  Every other Friday it will run a cumulative incremental.  As for the failed backup problem, you just check "allow after run day," and it will retry the backups until they succeed, and this won't mess in any way with when they'll run the next time.  Also, running manual full backups won't mess with the schedule either.

 

The manual tells you not to mix calendar and frequency backups.  I don't like calendar backups for daily backups, so some see this as a problem.  BUT I've found that if you monthly full, weekly cumulative, and daily (frequency based) incremental all have the same windows, the frequency-based schedule will take precedence and run when the others aren't running and the calendar backups will take precedence when it's time for them to run.  You just have to keep the windows the same.

 

The only goofy thing about calendar-based schedules (and it really annoys me) is that most people use a 6 PM to 6 AM clock (or some evening hour to some morning hour).  If you tell NBU to do the full on the 1st Friday of the month and leave all windows open, it will actually run the backup at just after midnight on Friday (Thursday night).  That's probably not what you wanted.  So you have to delete the window for the night before (in this case, Thursday).  I hate it, but I've learned to live with it.

 

Both methods have issues.  I prefer the predictability of the calendar-based method.

 

________________________________________________________

Curtis Preston | VP Data Protection
GlassHouse Technologies, Inc.

T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009
cpreston AT glasshouse DOT com | www.glasshouse.com
Infrastructure :: Optimized





This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

_______________________________________________
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