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 unix policies.  Just
say No.  

Personally, I follow the lead of others on this list and never install
VSP on a w2k3 or higher windows system--it's just one more flaky windows
device driver to deal with.  Go into host properties, master server,
clients, WOFB and set all w2k3+ clients to use VSS.  Set all windows
clients to not abort on snapshot error.

Use short names and lower case for everything since the GUIs present far
more information than will fit on a screen if you use
"WINDOWS-NORMAL-POLICY" rather than "win."  Depending on your locale
setting and changes Symantec makes to the GUI, upper-case generally
shows at the top of everything, like the policy tab.  Use that to make
exceptions stand out by rising to the top:  "TEMP-win."

There will be exceptions--the database that just _can't_ be backed up at
your normal windows, the huge fileserver that needs FlashBackup or has a
hundred filesystems, ...  Every exception is a complication.  Every
complication is more work and a distraction from more important things
you should be thinking about.


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu