The more important issue regarding DR is the prioritization of application restore based on the business itself. As it turns out, after a disaster about 90% of the stuff that's backed up isn't necessary to run the business. And the ability to get the previous seven days doesn't help either. More important to have two different DR pools: one for important data and one for the rest. Then optimize the important data DR pool to ensure it can do what you need it to do:
I must have application XYZ back up and available to users within 24 hours of the disaster to a point no further back than 48 hours. And it turns out that most business's ability to use recovered data within 24 hours is sketchy at best. Where are the people that use the data going to be? How will customers interact with them? All of these issues are actually about 100 times more difficult than restoring data. Yet few think of them! If you worry DR application by application and think about all aspects of using the data, the problem actually becomes simpler since there is less data to worry about the time frame to recover it is probably longer than you think. It's all about RPO and RTO. In our sales practice, I'm spending a lot of time consulting (during pre-sales so it's free) about DR issues. Bottom line: you need to have a very good plan, but since you will probably never execute (beyond testing), you probably shouldn't spend too much time/money on it. Kelly Lipp CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 x7105 www.storserver.com -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Howard Coles Sent: Tuesday, March 17, 2009 2:47 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Two different retention policies for the same node There could be some serious issues with this. If you have an onsite volume that has 170 day old data, with 5 day old data and 80 day old data (due to reclamation), and the volume goes bad, all you'll be able to restore is the 5 day old data. However, this is a real challenge. I'd like to see the solution. It appears on the surface that this is a result of is the "we want to keep it forever but can't afford the cost" mentality. Champagne taste on Beer budget. See Ya' Howard > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf > Of Michael Green > Sent: Tuesday, March 17, 2009 2:57 PM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] Two different retention policies for the same node > > I've been asked to provide a DR/BAckup solution that seems to > contradict TSM methodology, but I've decided I'll throw this in here > anyway. > > Given the following retention policy: > RETE=180 > RETO=180 > VERE=NOL > VERD=NOL > (180 days, no version limit) > > I've been asked to find a way to keep offsite only 7 days worth of > data (on deduped disk or somthng like that), both active and inactive. > So that it would allow us to restore complete system image from any > day within last week. > > Doable (without resorting to double backups under different MCs)? > -- > Warm regards, > Michael Green