Posted by: Eric Slack
Data protection, disaster recovery planning, Eric Slack, Gmail, Storage Channel
While a lot of attention is paid to natural disasters, the truth is that natural disasters don’t hold a candle to the man-made variety, in terms of the impact on IT and data protection. Events like the recent Gmail fiasco can be a watershed for smart VARs.
And while natural disasters underscore the random nature of catastrophes, they don’t make everyone feel vulnerable. Here in Colorado, CIOs don’t fear tsunamis or earthquakes like those experienced last week by the people of Japan, since we don’t live on any fault lines. But the problem that befell Google was not caused by external events but by a bug in storage software.
Apparently, corruption and data loss was propagated throughout the storage infrastructure with real-time replication — one could say, a different kind of wave. There are two messages that come out of this story that VARs can use to their advantage. First, if this can happen to Google, it can happen to anyone, anywhere. Second, simply relying on snapshots, replication and other complex forms of data protection that don’t actually make a copy of data (an off-site copy, if you’re concerned about big waves) can leave you vulnerable.
For VARs, the first thing to do is compile a good “elevator speech” to describe what happened. As is the case in technology, every point made requires some education. This topic, data protection and the vulnerability of abstract storage processes, is especially compelling for midmarket organizations since many people don’t really understand all that’s going on under the covers of their SAN. Of course, the reason to bring up problems is because you have an answer and in this case it’s a broad-based one. Users need to know what they’re doing when they set up critical processes like data protection. If they don’t know, they should get in touch with their “trusted advisor.”
Abstract processes like snapshots and change-based replication rely on a base data set being intact. In this case, the solution could involve something as simple as a periodic copy made to an independent storage system (even to tape). Think of it as the gap in the line of dominoes; the problem stops here. Another area of concern is the simple reliance on getting data back and not on getting applications up and running. Applications are getting more complex and often involve more than one server — like a database back end to a Web front end, for example. The importance of “application aware availability” is a key message, one that touches several systems and one that VARs are uniquely qualified to deliver. In the final analysis, disasters can help VARs generate the right kinds of discussions and focus attention on their potential value.
Follow me on Twitter: EricSSwiss