It seems that sometimes we forget the third letter in the acronym “DRP” (Disaster Recovery Planning). The “P” stands for “planning” and it is something that busy data center administrators replace with “make it up as you go along”. The reason for this state of affairs is the pace at which new servers, applications and storage systems are stood up while IT staffing and budgets remain flat. Organizations don’t have the time or money to plan for a disaster. They have to do the best they can when and if an event occurs. The problem is that hope is not a strategy, especially when it comes to surviving a disaster and proper planning can save you time and money.
Learning from Someone Else’s Mistakes
As an example I recently encountered an organization that was going through a disaster. It lost use of its primary building and their data center. The organization did have a recovery site with the appropriate equipment to start the recovery. The expectation of the business was they should be back up and running in a day (generous by today’s standards). The problem was when administrators got to the recovery site they did not have a copy of the backup software installed on the recovery server nor did they have a copy of the software available to them. The organization had to download an evaluation copy of the software from the vendor’s web site. That vendor restricted the evaluation version to only be able to backup and restore 2TBs of data. The customer had far more than that.
Finally the recovery device was a tape library. I am a proponent of tape in the right circumstances but tape should not be your first point of recovery (unless you have done some very sophisticated planning).
Before Disaster Strikes
Knowing what you are going to do and how you are going to do it BEFORE a disaster hits is critical to successfully navigating your way through a disaster. Testing does two things for you. First, it identifies silly mistakes (like not having the backup software) and it gives you practice so when a disaster strikes you can efficiently recover even while under a lot of duress.
Part of the “before” process is identifying which data you need to recover in the event of a disaster. It’s the most critical aspect for developing your plan.The reality is to survive a disaster most organizations need less than 5 percent of their total dataset. Most of the emphasis should be on returning specific applications to production. In the modern data center most of the data is unstructured and while important does not typically need to be recovered, at least initially, in a disaster.
Another key step is to identify dependencies for these applications. Does the application server need other services (and servers) to be online prior to it starting up? For example many will need a DNS or Active Directory server running prior to starting up. Others may need web services or some database back end. Identifying these dependencies and the specific order in which they should start is also critical to recovery.
Knowing what to do before a disaster strikes is an important first step to developing a disaster recovery plan. We cover this step and the two other steps (what to do during a disaster and what to do after a disaster) in our on demand webinar “DRaaS vs. DIY DR – Which is Best For Your Organization?” In this webinar we cover whether you should attempt to create your DR site or leverage a service.