Andrew Miller wrote:
Phew...that triggers a lot of thoughts....could almost sit down for 30-60 minutes and have a nice free-ranging discussion on this one. So...
- In some ways, it's not really all that hard....more just tedious. After all, all our data protection methods are artificial constructs based on technology limits (whether limits in technology at the time or the specific product). From a business perspective, it becomes incredibly obvious that they're artificial constructs....business drives the retention/frequency/RPO/RTO/etc. and therefore you have to map this constantly changing set of technical options (constantly changing from a long-term perspective) to a constantly changing set of business needs. Inevitably, there's someone who has to be a technical/business bridge there. While we say that "business should drive the requirements", the business perspective really could care less about the artificial constraints we happen to have...which leads into....
- Option overload -- in some cases, I almost think it's better to give a canned set of options rather than laying out possibilities (just to avoid option overload). That definitely varies on the organization. Even a technical person really can't be truly aware of the in-depth details of all the options (i.e. can anyone really actually know the ins and outs of SnapMirror/Vault vs. RecoverPoint vs. Exchange log shipping vs. DoubleTake vs. etc.)
- RPO & RTO -- these are great metrics from a DR perspective but there's nothing quite as simple when talking about actual backups or archives (and depending on the products you're looking at the lines get all fuzzy between all those ideas given how various products address multiple areas to varying degrees).
- Time -- ultimately data protection is an insurance policy....and we know how much we love to pay insurance premiums, right? All the time research, implementing, administering, validating, testing is ultimate our "premium". In a busy environment with lots of projects, it's easy to let that stuff slide...not quite get the attention it really needs (yes, there are architectural decisions that can help with this....but ultimately any IT solution does require some regular "care and feeding".
So...that's a first pass at least....
And the second pass?
Okay, so what you're saying is "data protection" in and of itself really isn't that difficult the difficulty lies in the technology limits that surround the opportunity which creates a challenge.
I agree with you that the business or as I have often put it, the business owners drive the retention/frequency/RPO/RTO, etc. - but if the business is a customer to a service that IT is providing, shouldn't they (the business) be concerned with "what its going to take" to meet their goals and objectives for their retention/frequency/RPO/RTO (as that may increase the price of their service)? Really what you're describing is the need to have a sound business impact analysis that can then be mapped to the appropriate technology solution. Correct?
As for RPO/RTO - I believe you're correct with regards to DR - however, I do believe RTO can applie to operational recovery. The only way to have a good handle on what all of this looks like is to have a solidly written Business Continuity Plan and Disaster Recovery Plan.
Maintaining the business through any unforeseen "Business Interruptions" is the mitigation of risk through your operational data protection plan and strategy (ie. Backup/Recovery). What time period converts a Business Interruption to a Disaster? Only determined through the analysis of the business and the value of the data to that business.
Definitely concur, DP is an insurance policy, but getting back to your business/technical bridge - someone needs to own that the insurance policy is up to date - otherwise all the investment in the "premiums", as you have described, would be money down the drain.
Data Protection is tedious, it requires a great deal of thought, it does require planning - but you still hold firm that DP isn't that difficult?
Looking forward to your second pass.
-chapa
