When Protecting Specific Applications, Start at the Beginning

The convergence of IT systems, and IT teams and resources, is happening on a ongoing basis. In the attached paper from DCIG, the firm cites  an IDC report putting the growth of the “converged infrastructure market” at 54 percent over the next three years (versus a 1.2 percent growth for the general infrastructure market). A healthy growth rate indeed, but the specific numbers aren’t as important as the fact that convergence is happening and as IT teams, we need to face that reality.

But it won’t be a light switch where everything changes at once, and for some time there will be specific applications that need individual attention. For these applications, such as databases, which may have been a specialty of one person in the past but are now the responsibility of a converged team that may not have as deep knowledge, the key is simplicity.

Luckily, many of the larger tenets of a smart backup and recovery plan hold true for application specific solutions. If you are looking for best practices and tips on protecting databases, specifically Oracle, the attached paper from DCIG provides some great information.

But before we get there, it’s important to review some important points in data protection planning, as they all apply to your approach with Oracle.

So without further ado, here are the first four steps we recommend businesses follow when building a smarter (read; more simple) backup and disaster recovery plan:

1.  Conduct an asset inventory

Yes, it probably goes without saying, but you can’t start planning without first knowing what your environment looks like. This is where you’ll want to collect information on all IT assets. In the case of application-specific scenarios, you want to know the basics. Which applications is the business running? Are there any dependencies inside this system? How much data is involved?

 2.  Perform a risk assessment

Once you’ve mapped out your infrastructure and identified dependencies, this is where you answer the question of “what if” X, Y or Z happens. That can take the form of outages and crashed, but in the case of databases, it includes the corruption of those databases and how the data (corrupt or otherwise) gets moved or replicated through the system.

 3.  Define the criticality of applications and data

At face value, this one’s pretty simple. Your company’s database is more important than your co-worker’s secret BitTorrent server. However, this step shouldn’t be skipped or quickly worked through. Restoring business-critical applications requires you to first understand which ones are actually critical, and more importantly, gain mutual agreement on the level of criticality across business units. There can be some hard decisions here, but they need to be made.

 4.  Define Recovery Objectives

Here’s where a lot of people get tripped up. We oftentimes see IT pros set recovery objectives without consulting application owners and business line managers. Guess what happens when your IT-defined SLAs don’t match the business expectations? Not a great place to be. It’s important we set our objectives collaboratively to ensure our plan is effective.

Hopefully this is useful information regardless of whether you’re interested in general disaster recovery planning or specifically protecting your Oracle database. For more info on the latter, please take some time to look at the attached DCIG report.