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

[Andrew White]

On Sat, Dec 13, 2008 at 10:31 AM, Curtis Preston 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 1
> st 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
> cpres...@glasshouse.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@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
___
Veritas

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

[Curtis Preston]

Hmmm... Looks like I've got some testing to do.



Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: +1 760 710 2009  
cpres...@glasshouse.com |  www.glasshouse.com
Infrastructure :: Optimized

-Original Message-
From: veritas-bu-boun...@mailman.eng.auburn.edu 
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of A Darren Dunham
Sent: Friday, December 12, 2008 3:57 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] How to plan out policy(schedules), [...]

On Fri, Dec 12, 2008 at 06:31:20PM -0500, Curtis Preston wrote:
> 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.

I know this happens to a lot of folks, but I've never experienced this
in 5.1 and 6.0.

I have "midnight-crossing" start windows and Full backup schedules set
for "last day of month".  They all start at the opening of the window on
the afternoon of the last day, not at midnight that day (which would be
valid, but is part of the previous day's window).

Not sure what my installation is doing that others aren't, but I'm very
happy it works this way.

-- 
Darren
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu





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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[A Darren Dunham]

On Fri, Dec 12, 2008 at 06:31:20PM -0500, Curtis Preston wrote:
> 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.

I know this happens to a lot of folks, but I've never experienced this
in 5.1 and 6.0.

I have "midnight-crossing" start windows and Full backup schedules set
for "last day of month".  They all start at the opening of the window on
the afternoon of the last day, not at midnight that day (which would be
valid, but is part of the previous day's window).

Not sure what my installation is doing that others aren't, but I'm very
happy it works this way.

-- 
Darren
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Curtis Preston]

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_ 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
cpres...@glasshouse.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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Curtis Preston]

I am a proponent of the one-client-per-policy design.  I've blogged about it:

http://www.backupcentral.com/content/blogsection/4/47/



Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: +1 760 710 2009  
cpres...@glasshouse.com |  www.glasshouse.com
Infrastructure :: Optimized

-Original Message-
From: bob944 [mailto:bob...@attglobal.net] 
Sent: Friday, December 12, 2008 9:47 AM
To: veritas-bu@mailman.eng.auburn.edu
Cc: Curtis Preston
Subject: RE: [Veritas-bu] How to plan out policy(schedules), [...]

> This is a really well-thought-out answer to his question.  
> Although I don't agree with ALL of your recommendations (I 
> don't like frequency-based schedules for fulls), this is 
> actually a pretty good summary of what someone should do to 
> setup a new backup environment.  You've inspired me to blog 
> about the same.  (Of course, I may use my own opinions...) ;)

Thank you, Curtis.  I'm just a simple guy; complex setups make my hair
hurt and I've have had enough "Oops, forgot about " moments that I
use simplicity to minimize them.

The other approach that I love (though I'd never implement it unless I
had beaucoup time to get the coding right end-to-end) is the exact
opposite:  one person on this list (sorry, I don't rember who you are)
who has a bajillion clients with a policy for each one with an automated
setup, like a scratch-built backup provisioning system.  Took a week for
the concept to grow on me, and I can see it for a very experienced shop
with a fluid mix of clients.






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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Rusty . Major]

Man in the suit,

I'd like to hear your reasons against frequency based scheds.

For my situation, I want a full backup once a week, once a month, once a 
quarter, once a year, etc. *I* don't care when it happens, though my 
customer might, though in most circumstances, backups should not hinder 
the performance of the box. In situations where a customer needs a backup 
on a specific day/day of the month, we'll use calendar, but I personally 
hate calendar because of the extra administration effort required to set 
it up so you don't suddenly stop getting backups in 2015 because someone 
was lazy and didn't finish it out.

Rusty Major, MCSE, BCFP, VCS ▪ Sr. Storage Engineer ▪ SunGard 
Availability Services ▪ 757 N. Eldridge Suite 200, Houston TX 77079 ▪ 
281-584-4693
Keeping People and Information Connected® ▪ 
http://availability.sungard.com/ 
P Think before you print 
CONFIDENTIALITY:  This e-mail (including any attachments) may contain 
confidential, proprietary and privileged information, and unauthorized 
disclosure or use is prohibited.  If you received this e-mail in error, 
please notify the sender and delete this e-mail from your system. 



"Curtis Preston"  
Sent by: veritas-bu-boun...@mailman.eng.auburn.edu
12/12/2008 09:55 AM

To
, 
cc
boloba...@gmail.com
Subject
Re: [Veritas-bu] How to plan out policy(schedules), [...]






Bob,

This is a really well-thought-out answer to his question.  Although I 
don't agree with ALL of your recommendations (I don't like frequency-based 
schedules for fulls), this is actually a pretty good summary of what 
someone should do to setup a new backup environment.  You've inspired me 
to blog about the same.  (Of course, I may use my own opinions...) ;)



Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: +1 760 710 2009  
cpres...@glasshouse.com |  www.glasshouse.com
Infrastructure :: Optimized

-Original Message-
From: veritas-bu-boun...@mailman.eng.auburn.edu 
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of bob944
Sent: Saturday, December 06, 2008 6:37 PM
To: veritas-bu@mailman.eng.auburn.edu
Cc: boloba...@gmail.com
Subject: Re: [Veritas-bu] How to plan out policy(schedules), [...]

All other advice you receive will be more complicated and that's fine if
it makes more sense to you.  My philosophy here is to make your
NetBackup as simple and self-maintaing as possible; every exception (and
there will be some) is a cost.

> I am very new to NBU. Our enviornment has 300 intell and 100 
> unix system.We have 1 master ( sun t5120) for entire
> enviornment and 2 media ( sun x4500 disk storage) for lan
> based backup. one media server ( sun t5220 ) for SAN
> client for exchange and RMAN. One more media server ( sun
> t5220 ) for NDMP backup. We also have stk 8500 tape library.

So you need a (emphasis: "a") windows policy, a standard, an Exchange,
an Oracle and an NDMP.  If you'll have long-running backups, set as long
a checkpoint interval as you can stand.  Give every policy some default
priority, say, 1000 (sooner or later, you'll have something that should
run as low-priority but if all the policies are 0, there's no lower
setting).  Set "allow multiple data streams."

> Our plan is to have 45 days retention for all data

Personally, I wouldn't save incremenal data for more than two fulls, but
since a single retention period is simpler and meets your needs, let's
use it.  But rather than create a custom retention period let's use one
that's already in NetBackup, say "2 months."  (Though I love to fiddle
with and customize things personally, I prefer to leave everything as
"stock" as possible and still meet the business requirements--every
customization adds to the list of things that have to be replicated in
the future.  If you have a Real Business Need for 45 days, or if the
extra retention will cause you to buy more storage, then go ahead and
customize a retention level.)

> and do increamental daiy and full on weekend. 

Don't do that.  Figure out your backup window, say 2000-0600, and set
full and incremental frequency-based schedules the same, every day.
(Remember that the end time of a window is the last time a policy can
automatically _start_, so if a queued backup starting at 0550 and
running for a couple of hours is too late, use an earlier time than
0600.)  Your weekly fulls will run every seven days (and that day's
incremental will not).  (There are half a dozen ways to avoid doing a
disproportionate number of fulls on a weeknight; the simplest is to just
add, say, 10% of your clients to policies every weekday and the rest on
Friday; a client/policy's first backup will be a full.) 

For windows and standard policies selection lists:  ALL_LOCAL_DRIVES.
Set up (you and/or your clients) exclu

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

[bob944]

> This is a really well-thought-out answer to his question.  
> Although I don't agree with ALL of your recommendations (I 
> don't like frequency-based schedules for fulls), this is 
> actually a pretty good summary of what someone should do to 
> setup a new backup environment.  You've inspired me to blog 
> about the same.  (Of course, I may use my own opinions...) ;)

Thank you, Curtis.  I'm just a simple guy; complex setups make my hair
hurt and I've have had enough "Oops, forgot about " moments that I
use simplicity to minimize them.

The other approach that I love (though I'd never implement it unless I
had beaucoup time to get the coding right end-to-end) is the exact
opposite:  one person on this list (sorry, I don't rember who you are)
who has a bajillion clients with a policy for each one with an automated
setup, like a scratch-built backup provisioning system.  Took a week for
the concept to grow on me, and I can see it for a very experienced shop
with a fluid mix of clients.


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[WEAVER, Simon (external)]

I agree with Ed
I am the guy in the Jeans and T-Shirt.
 
1) Nowt wrong with frequency schedules for Fulls! Use them all the time
2) Keep the Policies and Volumes to a LESS as possible. 
3) Over complexing the system makes NBU harder to administer than it
really, really needs to be !
 
Simon (White Shirt, Jeans, Trainers, NBU Admin)  :-)



From: veritas-bu-boun...@mailman.eng.auburn.edu
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Ed Wilts
Sent: Friday, December 12, 2008 3:54 PM
To: Curtis Preston
Cc: bob...@attglobal.net; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] How to plan out policy(schedules), [...]


On Fri, Dec 12, 2008 at 9:34 AM, Curtis Preston
 wrote:


Bob,

This is a really well-thought-out answer to his question.
Although I don't agree with ALL of your recommendations (I don't like
frequency-based schedules for fulls), this is actually a pretty good
summary of what someone should do to setup a new backup environment.
You've inspired me to blog about the same.  (Of course, I may use my own
opinions...) ;)


The key opinion that we all know you'll disagree with is one policy per
server, which Bob apparently doesn't like and we know that you.  "The
man in the suit" vs "the man in the yellow shirt" discussion, for those
of who were at the customer forum in Roseville in October.  :-)

Personally, I agree with Bob on frequency-based schedules for fulls.
Calendar-based schedules only make sense if you have a strict business
requirement for say, an end-of-quarter backup after the books close.

The key thing to always remember is to keep things as absolutely simple
as possible.  Make it easy for other people (new employees, support
folks, contractors) to see what the heck you've done a year or more
after you set it up.  The more complicated you make it, the harder it is
to support.  The more you deviate from a "normal" configuration, the
more likely it is you'll trigger bugs in future NetBackup releases.
Simple is good.


.../Ed 

Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE 
ewi...@ewilts.org



This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from disclosure.
If you are not the intended recipient, please notify the sender
immediately, do not copy this message or any attachments and do not use it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and all
liability if this email transmission was virus corrupted, altered or
falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Ed Wilts]

On Fri, Dec 12, 2008 at 9:34 AM, Curtis Preston wrote:

> Bob,
>
> This is a really well-thought-out answer to his question.  Although I don't
> agree with ALL of your recommendations (I don't like frequency-based
> schedules for fulls), this is actually a pretty good summary of what someone
> should do to setup a new backup environment.  You've inspired me to blog
> about the same.  (Of course, I may use my own opinions...) ;)


The key opinion that we all know you'll disagree with is one policy per
server, which Bob apparently doesn't like and we know that you.  "The man in
the suit" vs "the man in the yellow shirt" discussion, for those of who were
at the customer forum in Roseville in October.  :-)

Personally, I agree with Bob on frequency-based schedules for fulls.
Calendar-based schedules only make sense if you have a strict business
requirement for say, an end-of-quarter backup after the books close.

The key thing to always remember is to keep things as absolutely simple as
possible.  Make it easy for other people (new employees, support folks,
contractors) to see what the heck you've done a year or more after you set
it up.  The more complicated you make it, the harder it is to support.  The
more you deviate from a "normal" configuration, the more likely it is you'll
trigger bugs in future NetBackup releases.   Simple is good.

.../Ed

Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE
ewi...@ewilts.org
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Curtis Preston]

Bob,

This is a really well-thought-out answer to his question.  Although I don't 
agree with ALL of your recommendations (I don't like frequency-based schedules 
for fulls), this is actually a pretty good summary of what someone should do to 
setup a new backup environment.  You've inspired me to blog about the same.  
(Of course, I may use my own opinions...) ;)



Curtis Preston  |  VP Data Protection  
GlassHouse Technologies, Inc.
 
T: +1 760 710 2004 |  C: +1 760 419 5838 |  F: +1 760 710 2009  
cpres...@glasshouse.com |  www.glasshouse.com
Infrastructure :: Optimized

-Original Message-
From: veritas-bu-boun...@mailman.eng.auburn.edu 
[mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of bob944
Sent: Saturday, December 06, 2008 6:37 PM
To: veritas-bu@mailman.eng.auburn.edu
Cc: boloba...@gmail.com
Subject: Re: [Veritas-bu] How to plan out policy(schedules), [...]

All other advice you receive will be more complicated and that's fine if
it makes more sense to you.  My philosophy here is to make your
NetBackup as simple and self-maintaing as possible; every exception (and
there will be some) is a cost.

> I am very new to NBU. Our enviornment has 300 intell and 100 
> unix system.We have 1 master ( sun t5120) for entire
> enviornment and 2 media ( sun x4500 disk storage) for lan
> based backup. one media server ( sun t5220 ) for SAN
> client for exchange and RMAN. One more media server ( sun
> t5220 ) for NDMP backup. We also have stk 8500 tape library.

So you need a (emphasis: "a") windows policy, a standard, an Exchange,
an Oracle and an NDMP.  If you'll have long-running backups, set as long
a checkpoint interval as you can stand.  Give every policy some default
priority, say, 1000 (sooner or later, you'll have something that should
run as low-priority but if all the policies are 0, there's no lower
setting).  Set "allow multiple data streams."

> Our plan is to have 45 days retention for all data

Personally, I wouldn't save incremenal data for more than two fulls, but
since a single retention period is simpler and meets your needs, let's
use it.  But rather than create a custom retention period let's use one
that's already in NetBackup, say "2 months."  (Though I love to fiddle
with and customize things personally, I prefer to leave everything as
"stock" as possible and still meet the business requirements--every
customization adds to the list of things that have to be replicated in
the future.  If you have a Real Business Need for 45 days, or if the
extra retention will cause you to buy more storage, then go ahead and
customize a retention level.)

> and do increamental daiy and full on weekend. 

Don't do that.  Figure out your backup window, say 2000-0600, and set
full and incremental frequency-based schedules the same, every day.
(Remember that the end time of a window is the last time a policy can
automatically _start_, so if a queued backup starting at 0550 and
running for a couple of hours is too late, use an earlier time than
0600.)  Your weekly fulls will run every seven days (and that day's
incremental will not).  (There are half a dozen ways to avoid doing a
disproportionate number of fulls on a weeknight; the simplest is to just
add, say, 10% of your clients to policies every weekday and the rest on
Friday; a client/policy's first backup will be a full.)  

For windows and standard policies selection lists:  ALL_LOCAL_DRIVES.
Set up (you and/or your clients) excludes for database files, for
netbackup/db/images and your disk STUs (yes, include your NetBackup
servers in the standard policy for simplicity) and for any other data
the client doesn't want/need backed up and make the client responsible
for managing it--that's why exclude/include lists are on the client in
the first place.  For database policies, have all clients use the same
name and location for the script.

> As of now we not planning for cloning ( VAULT ( offsite)). There
> is alos plan to migrate data if LAN media server ( x4500) fills
> to 80%  to Tape library. NDMP and SAN client backup will go
> directly to 8500.

That sounds as if you're going to have one copy of some backups on disk
(only) and one copy of others on tape (only).  If the loss of backups
due to failed disk or failed tape is acceptable, fine.  If that's not
acceptable, use Storage Lifecycle Policies to do the duplications; SLPs
can easily do duplications integrated into the backup period rather than
the big vault batches usually done in off-hours.  Two SLPs (one
disk-to-tape, the other tape-to-tape) will cover both duplications in
your setup.  Use the storage unit groups for destinations.

> stgunit, stggroup, 

Storage units are almost self-defining.  Device discovery for the tape
drives and supply a disk path to create basic disk storage units.
Reduce the

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

[bob944]

All other advice you receive will be more complicated and that's fine if
it makes more sense to you.  My philosophy here is to make your
NetBackup as simple and self-maintaing as possible; every exception (and
there will be some) is a cost.

> I am very new to NBU. Our enviornment has 300 intell and 100 
> unix system.We have 1 master ( sun t5120) for entire
> enviornment and 2 media ( sun x4500 disk storage) for lan
> based backup. one media server ( sun t5220 ) for SAN
> client for exchange and RMAN. One more media server ( sun
> t5220 ) for NDMP backup. We also have stk 8500 tape library.

So you need a (emphasis: "a") windows policy, a standard, an Exchange,
an Oracle and an NDMP.  If you'll have long-running backups, set as long
a checkpoint interval as you can stand.  Give every policy some default
priority, say, 1000 (sooner or later, you'll have something that should
run as low-priority but if all the policies are 0, there's no lower
setting).  Set "allow multiple data streams."

> Our plan is to have 45 days retention for all data

Personally, I wouldn't save incremenal data for more than two fulls, but
since a single retention period is simpler and meets your needs, let's
use it.  But rather than create a custom retention period let's use one
that's already in NetBackup, say "2 months."  (Though I love to fiddle
with and customize things personally, I prefer to leave everything as
"stock" as possible and still meet the business requirements--every
customization adds to the list of things that have to be replicated in
the future.  If you have a Real Business Need for 45 days, or if the
extra retention will cause you to buy more storage, then go ahead and
customize a retention level.)

> and do increamental daiy and full on weekend. 

Don't do that.  Figure out your backup window, say 2000-0600, and set
full and incremental frequency-based schedules the same, every day.
(Remember that the end time of a window is the last time a policy can
automatically _start_, so if a queued backup starting at 0550 and
running for a couple of hours is too late, use an earlier time than
0600.)  Your weekly fulls will run every seven days (and that day's
incremental will not).  (There are half a dozen ways to avoid doing a
disproportionate number of fulls on a weeknight; the simplest is to just
add, say, 10% of your clients to policies every weekday and the rest on
Friday; a client/policy's first backup will be a full.)  

For windows and standard policies selection lists:  ALL_LOCAL_DRIVES.
Set up (you and/or your clients) excludes for database files, for
netbackup/db/images and your disk STUs (yes, include your NetBackup
servers in the standard policy for simplicity) and for any other data
the client doesn't want/need backed up and make the client responsible
for managing it--that's why exclude/include lists are on the client in
the first place.  For database policies, have all clients use the same
name and location for the script.

> As of now we not planning for cloning ( VAULT ( offsite)). There
> is alos plan to migrate data if LAN media server ( x4500) fills
> to 80%  to Tape library. NDMP and SAN client backup will go
> directly to 8500.

That sounds as if you're going to have one copy of some backups on disk
(only) and one copy of others on tape (only).  If the loss of backups
due to failed disk or failed tape is acceptable, fine.  If that's not
acceptable, use Storage Lifecycle Policies to do the duplications; SLPs
can easily do duplications integrated into the backup period rather than
the big vault batches usually done in off-hours.  Two SLPs (one
disk-to-tape, the other tape-to-tape) will cover both duplications in
your setup.  Use the storage unit groups for destinations.

> stgunit, stggroup, 

Storage units are almost self-defining.  Device discovery for the tape
drives and supply a disk path to create basic disk storage units.
Reduce the fragment size only if you will be doing significant smounts
of individual file restores.  Multiplex the tape STUs to something like
8 or even 32 (and control the actual multiplexing used in the schedules)
Since you want some backups on tape and others on disk, create one group
for all the tape storage units and one for all the disk STUs and set
them to load balance.

> pools etc ?  

One production pool.  Either use DataStore or make _one_ up for your
datacenter.  With your current plans, you don't need an
offsite/duplicate pool or offsiteDB pool,  You will need a scratch pool
(and set up a barcode rule to put all new tapes into it) and a test pool
(do not use your production tapes for testing).  Do add a duplicate pool
if you ,make duplications as above.

Set up the hot catalog backup, full backup, every day.

Tell your clients what you will provide them (as you detailed in your
message); do not ask them what they would like.  They probably know
nothing about backup and recovery, what they do know will be wrong, and
you will have 300 unique windows policies and 300

[Veritas-bu] How to plan out policy(schedules), stgunit, stggroup, pools etc ...

[bolobaboo kabootar]

Hi
I am very new to NBU. Our enviornment has 300 intell and 100 unix system.We
have 1 master ( sun t5120) for entire enviornment and 2 media ( sun x4500
disk storage) for lan based backup. one media server ( sun t5220 ) for SAN
client for exchange and RMAN. One more media server ( sun t5220 ) for NDMP
backup. We also have stk 8500 tape library.
 Our plan is to have 45 days retention for all data
and do increamental daiy and full on weekend. As of now we not planning for
cloning ( VAULT ( offsite)). There is alos plan to migrate data if LAN media
server ( x4500) fills to 80%  to Tape library. NDMP and SAN client backup
will go directly to 8500.
  Now big question infront of me how do i plan for
policy(what would be their schedule) , stgunit, stggroup, pools etc ?  Is
there any body can assists me in planning these ? I am looking for your
expertise, don't want make mesh then rip apart in future and start all over
again.
  Thank you again.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu