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

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" <cpreston AT glasshouse DOT com>
Sent by: veritas-bu-bounces AT mailman.eng.auburn DOT edu

12/12/2008 09:55 AM

To	<bob944 AT attglobal DOT net>, <veritas-bu AT mailman.eng.auburn DOT edu>
cc	bolobaboo AT gmail DOT 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 cpreston AT glasshouse DOT com | www.glasshouse.com Infrastructure :: Optimized -----Original Message----- From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of bob944 Sent: Saturday, December 06, 2008 6:37 PM To: veritas-bu AT mailman.eng.auburn DOT edu Cc: bolobaboo AT gmail DOT 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 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 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