Considerations for Disaster Recovery Part 1 of 3

I finally decided to write a series of blogs about things that I spend a lot of time talking about—to customers, partners (not the wife; she never listens to anything I say) and pretty much anyone who'll listen.


A lot of people talk about backup and recovery as a last thing on a shopping list for project that has been completed without the realisation that they need some form of data protection or a disaster recovery plan.


For some reason, businesses and IT teams leave out data protection until absolutely necessary—or until they have had a data loss issue. Admittedly, it's like watching paint dry, but it's possibly one of the most important IT activities a business needs to be successful.


So to make this topic a little less toxic (seems to be a buzzword at the moment), I've broken it down into 3 chunks (sorry, no dedupe here), each chunk—or blog post—includes one or two questions I frequently get asked and some of my thoughts around them.


Q: What Data?


A: Deciding what data is important to your business is a major consideration in what you’ll need to implement in your disaster recovery plan. Understanding the business needs will play a major part in this too. Do you need email? Do you need archived data? A good starting point is to consider classifying the types of data you have in your environment. These usually fall into three main types: static data, business vital and mission critical.


With a classification of the data completed it becomes a little easier to define what you need to protect and how you protect that data. With different levels of protection available for different data classifications, some will become relevant for true DR while others may not be so important. It’s good to remember that all data in a business is a business asset and still needs to be protected at some level.


Looking at the core business data will determine how you approach your DR strategy. More often than not a ‘one solution fits all’ is not appropriate for the different data classifications. For example why would you need a high speed recovery solution for static data that hasn’t been looked at for 90 days? Is it business critical? Probably not. By defining the datasets that you will need in a disaster can help reduce costs by assigning the appropriate technologies and resources to match budgets.


All you may need is the current data in use and the core delivery systems, email, databases, web servers etc.


Q: How fast do you need that data back, what data are you willing to sacrifice?


A: No matter what protection you have in place there will always invariably be an amount of data you will not be able to recover. It sounds strange to say that—seeing as there are so many technologies about today; but the truth of the matter is that there is a need to determine which data you can do without. This is usually transient data that is not captured between backups. Having determined your data classification, this will assist in working out what level of data loss is acceptable to the business based on the data classification.


Let’s imagine, for example, you cannot run your business without a particular SQL database. It is a major revenue tool. Then you are going to need to minimise the data loss, perhaps to a near zero requirement, look towards CDP solutions. Data that is not mission critical but vital to the business will need protection with a faster restore method. Again, choosing an appropriate technology for this data could represent cost savings when compared to having a single high end solution for everything, here disk-based backup with deduplication to help reduce storage costs.


Two things that need to be considered: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO measures the time it’s going to take to make your data available for use again by your end users. This is important: the time to recover data is not the time it takes the IT guy to find the tape kept behind the pot plant on the boss’s desk. It's the time it will take for the users to start working on the data again. RPO is usually the last backup point in time or the point in time you are going to recover data to. For mission-critical application data, this needs to be less than 5-minute intervals—so you can minimise data loss.


The data that is business vital still needs to be protected, but perhaps nightly based incremental is sufficient for that. Now that we have our data protected in a way that suits our business needs we need to understand where we keep that protected data and how that can influence the technology decisions we need to deploy.


In my next blog in this series, I’ll tackle hot and cold DR sites and how to efficiently send backup data over a wide area network. Stay tuned!


Continue to Part 2

Skip forward to the end: Part 3