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