It’s an all too familiar occurrence for businesses today: something goes wrong – from the simple accidental deletion, to the loss of an entire building’s worth of data – and IT is supposed to make it all better. Right now. (Is it done yet?)
This is not always the easiest task to accomplish. Why? Because you don’t necessarily have the right backup and recovery solution in place to assist you. To be candid, this most definitely isn’t a pitch for a specific solution, but it may be worth considering that you are using the wrong one – or are simply using the one you have incorrectly.
How are you supposed to tell which solution is the right one?
The answer doesn’t lie in a list of software or hardware features. Instead, it revolves around looking at the industry buzz phrase itself for the answer – Disaster Recovery. To choose the right solution, we’re going to break the process up into its two main parts – disaster and recovery – and cover each over a two-part blog mini-series.
How can you plan for recovery if you don’t know what you’re protecting against?
In this first blog, we’ll look at defining the disasters. After all, it’s impossible to plan your recovery if you don’t know what the disaster is you’re protecting against in the first place. In the second part, to be published next week, we’ll talk about applying the disasters to recovery scenarios. From here you’ll be able to translate these scenarios into product features to work backwards to a solution that meets your needs.
So, what are the disasters you need to protect against?
Below is a list of potential “disasters” – the point is for you to identify which ones are important to you (or your customer if you’re an MSP).
• Loss of Data – This could be as simple as a user deleting a folder rather than a file. If that user is your CEO, it’s pretty important. But it could also be a case of ransomware that encrypts every file on your file server, or a database that becomes corrupt.
• Loss of an Application – Think along the lines of changes to security or system configurations, or even updates that negatively impact services. If you can’t figure out what caused the service outage, you’re going to need to recover the application.
• Loss of a System – This could be a hardware failure, or for those of you with virtualized servers, a crashed OS.
• Loss of Connectivity – This one may not seem like a situation for a backup solution, but should you have an application hosted inside the four walls that is used externally, you may need to consider recovering that application to an external site.
• Loss of Business Location – think electrical outage, fire (and resulting flooding from sprinklers), even a chemical spill outside the building. Anything that keeps your employees from using the business facilities will require recovery to an alternate location.
• Loss of Operations – Any of the previous “disasters” can represent a complete stoppage of business operations. It’s important to recognize the importance of your data, applications, systems, connectivity, and locations, as you may need to respond with a completely different recovery strategy in different situations.
To truly define the disasters you want to protect against, you’ll need to define the loss instance granularity. (That’s a buzzword I just made up. Feel free to use it!) For example, you’re not going to treat all files on a file server with the same level of importance. You need to look at each data set and decide just how critical it is to the business. You’ll then need to do the same for applications, systems, etc.
In the second part of this blog series, we’ll discuss taking the disaster definitions, and applying both specific recovery objectives and methods to them, all in an effort to help you with choosing the right disaster recovery solution.
Read part two of this blog series: Choosing the right disaster recovery solution, part 2: Finding your feature set