Preparing for Disaster... Recovery


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

Lately I've been hearing people state that they need their file system or storage solution to have disaster recovery capability. I've just been listening and haven't really participated in the discussion, but I have noticed one thing: the general theme is "we need DR."

However, when you start asking questions such as "What do you mean by disaster recovery?" or "What data should be recovered?" or my favorite, "What kinds of disasters?" you find that the emperor is not wearing any clothes.

When you start probing beneath the surface of "We need DR," you find that the definition or even the use of the phrase "Disaster Recovery" is like swimming in the Hudson River — you can't see a thing. Basic questions like "what disaster?" or "what do you want to recover?" or "how quickly do you want to recover?" often have no answers.

To actually understand if you need a DR solution and under what conditions one is "designed," you should start asking yourself some simple questions. This planning for DR should not be taken lightly. The answers can have a big impact on the scale of your DR solution and ultimately, the cost.

The best place to start is to ask yourself about the meaning of disaster recovery.

What data do you want to recover or protect?

What data to you want to protect using DR? Another way to think about the question is, what data do you want to recover in the event of a disaster? Which data is absolutely critical to keeping your business, research institution or university functioning in the event of a disaster?

For example, do you want to recover all the data including emails, customer data (or student data), financial records, shipping records, general working data, and archive data? Or do you only want to recover data that ensures business continuity, such as customer information, financial records, and shipping records? These two answers are typically at opposite ends of the spectrum where the first option is "protect all data!" to the second option which is "protect only what is critical." Deciding where you fall in the spectrum is pretty important because the simple rule of thumb is that the more data you want to recover (or protect), the longer it will it take to protect and recover, and the more it will cost.

The best advice I can give is to focus on what DR is supposed to do — allow you to recover from a disaster. Which data allows you to keep functioning? Which data can be lost without detriment to the company?

One subtle point in this discussion is that you will have to keep in mind any compliance or regulatory information that might be required. Just because you can recover customer data and financial and shipping records does not mean that you are allowed to skip compliance and regulation requirements.

A great place to start is to make a simple list of the kinds of data you store today. It doesn't have to be detailed but rather just high-level. Then create a second list of the data you need to keep the company functioning. Again, just make a high-level list but you could add data to the list that gives "added functionality" to the company. Then you correlate the two lists and discover which data is absolutely necessary and which is "nice to have".

The second step might be to then discover where this data is being stored today and how the company is protecting it today (if it is). It might take a while to discover where the data is located but ultimately the exercise is useful because you now know which data is important and where it is. You can even use that information to start consolidating storage (that's another story).

Which Disasters?

A second question that is inexorably tied to the first question is "what do you mean by 'disaster'?" Specifically, what disasters do you want to recover from?

The list of possible disasters is huge, so let's create our own list by starting with a small disaster and then increase the magnitude of the disaster. For each disaster, I'm going to list the "scope" (how many people it affects within the company and even outside the company), the time scale for recovering from the disaster, the monetary impact of the disaster including a comment on the loss of data, and the ultimate cost of recovering from the disaster for the case of no DR capability. Also, I use the phrase "data center" to mean an actual data center or a co-location facility or something on-premise inside the company.

  • The cleaning crew pulls plug from your desktop so the data on your desktop is not accessible at that moment
    • Scope: One person
    • Time scale: A few minutes
    • Impact: Minimal with no loss of data (i.e. just a delay in accessing data)
    • Cost: $0
  • The hard drive in your desktop failed
    • Scope: One person
    • Time scale: A few minutes to a few hours
    • Impact: Minimal with possible loss of data
    • Cost: $50 - $1,000 ($1,000 if data needs to be recovered from drive)
  • The centralized storage for your company is not accessible (perhaps a power loss)
    • Scope: Potentially a large number of people
    • Time scale: A few minutes to a couple of hours
    • Impact: Minimal with possible loss of data in flight
    • Cost: Small
  • Failed drive(s) in the company centralized storage
    • Scope: Potentially a large number of people
    • Time scale: A few hours to a few days
    • Impact: Minimal. If recovery doesn't go well, data could be lost
    • Cost: Small but there is a performance impact in the case of a RAID rebuild

Submit a Comment


People are discussing this article with 0 comment(s)