Choosing the Right Disaster Recovery Solution: Part 2

In the first blog in this two-part series on determining how to choose the right disaster recovery solution, I covered the very first step – defining the disasters you need to protect against. The thinking is it’s nearly impossible to pick the right disaster recovery solution if you don’t know what you’re trying to protect. For example, if all you need to do is to be able to locally restore a single workstation, then purchasing a disaster recovery solution that includes a virtual recovery environment, and automated workflow is completely bonkers. So, if you haven’t read the first article, I recommend you stop here, take a quick read of it, and then jump back to this article and continue.

So, let’s assume you have your list of disasters you from which you wish to be able to recover. There are a few more steps that keep you just about right here in the conversation, as you need to dig a little deeper and think about each of the “disasters” and cross-reference them with the critical applications, data, systems, and endpoints you wish to protect during such a disaster. For example, when thinking about a loss of data, you might be thinking about a specific file server, and a few critical client endpoints. But when trying to protect against the loss of a location, you’re considering many more applications, endpoints, business processes, etc. The goal here is to make sure you know which parts of your environment need protecting, and from what disaster(s) they need to be protected.

Now, you might think “OK! So now I compare the list of systems and applications against a disaster recovery solution feature list, right?” Wrong.

You’re still not there. To be able to get to the point where you have a concrete set of SolarWinds Backup requirements from which to choose the right solution, you need to complete two additional steps.

Identify your recovery objectives

Putting specifics around the amount of time you have to recover (formally called the Recovery Time Objective, or RTO) and how much data you are willing to lose (called the Recovery Point Objective, or RPO) on a per-recovery data set basis is key. I listed “per-recovery data set” as each may have a different set of recovery objectives that will dictate what kind of backup model is necessary (read: one set of solution requirements), and what kind of recovery will be needed (read: another set of solution requirements).

For example, a mission critical application may have a RTO of less than 15 minutes, and a RPO of less than 30 minutes, whereas files on a file server can have a RTO of 1 day, and a RPO of anything less than 1 week. So each of these objectives translate into the answers to questions like:

• How often will I need to backup this data set?
• Can I backup at a file level or do I need to back it up as an Image?
• How would I recover this data set – to an alternate virtual environment, to the same server, or what?

Remember, you’ll need to apply these objectives to each combination of “disaster” and data to be protected, because getting an Exchange server back up when there’s a loss of data is a completely different backup and recovery exercise than when there’s a fire in the building causing the server to go up in flames.

Identifying these two recovery objectives for each protected data set and disaster will help to mold the final step.

Determine the backup and recovery methods

I’ve already hinted at this a bit, but it becomes the next logical step in the process – a step that will yield a set of technical requirements you’ll use to select a disaster recovery solution. By answering the questions I mentioned above (which were along the “How would I recover this?” line of questioning), you’ll start at the actual goal of disaster recovery – Recovery – and work backwards to what you need to back up and how it needs to be backed up.

Take the example of an Exchange server potentially going up in flames, and let’s walk through the process of spec’ing out the backup and recovery. The server room would be gone, and you need that back up and running within 30 minutes, without losing more than 30 minutes of data. Using these criteria, you’re going to need to be able to recover to an alternate location, use image-based backups (or you can’t meet the RTO of 30 minutes), have incremental backups no more than 30 minutes apart, and use some kind of continuous recovery strategy that restores the incremental image backup as it is generated.

See what you end up with here? A few entries in your list of disaster recovery solution requirements:

• Image-level backups
• Support for Windows
• Continuous recovery
• Data compression technology that can ensure backup and transmission of an Exchange server in less than 30 minutes

The right DR solution: Your recovery needs will dictate

I hope it’s evident that to truly have the right disaster recovery choice in mind, you need to walk through all these steps first in order to build out the true list of features, support, and capabilities necessary to recover your environment.

By considering the possible disasters, matching them (as necessary) with the data sets to be protected, and identifying what the needed recovery objectives look like, all in an effort to build a tactical requirements list for the actual backup and recovery, you can build the list that specifically meets your organization’s needs. Ultimately, this will help you choose the right disaster recovery solution.

Remember, there is no magic feature list – each of you will have a list that is unique. So, take the time to walk through this process and develop your list of requirements. That way, you’ll ensure the solution you choose will definitely meet your needs.