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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Howard Coles
Sent: Tuesday, March 17, 2009 2:47 PM
To: ADSM-L AT VM.MARIST DOT 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Michael Green
> Sent: Tuesday, March 17, 2009 2:57 PM
> To: ADSM-L AT VM.MARIST DOT 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
|