I’ve done a little disaster recovery planning in my day. As an IT Professional, it’s really easy to get caught up in the day-to-day. We have users that need assistance, servers that need love (updates), applications that need upgrading… whatever today’s problem is, it needed solving yesterday. Disaster Recovery is often the elephant in the room, the insurance you don’t have time to buy. Everyone knows it’s needed, no one ever wants to use it and often, there is no clear way to begin.
I’ve always thought that being an IT Pro is one of the most powerful, powerless jobs in existence. We have our fingers on the pulse of what makes our businesses run, we have access to ALL THE DATA and we have the power to control access and availability to the resources. But we are often slaves to the business – we are responsible for providing the best up times, the best solutions and the best support we can. Facing budgets we can’t always control while trying to explain technology to people who don’t have time to understand it.
So where do you begin when tasked with updating or creating your disaster recovery plan? The good news is you don’t need money or lots of extra hardware to start good disaster recovery planning – grab the note-taking tools of your choice and start asking questions.
Here are my three main questions to get started:
- What is the most important application or services in each business unit or for the business overall?
- How much downtime is acceptable?
- How much data loss is acceptable?
These are your considerations. Period. I didn’t mention money, but I know you want to argue that you can’t recover without it. And that is true. But until you know what your goal is, you have no idea how much it may or may not cost.
This post is one of many in disaster recovery series being penned by the IT Pro Evangelists at Microsoft. As the series progresses, you’ll find the complete list on Brian Lewis’s blog post, “Blog Series: DR Planning for IT Pros.” We will cover tools and applications you can consider in you planning and get you started with using them. They have various costs, but until you know your goal, you won’t know what tools will help and can’t argue the budget.
So let’s put the pencil to the paper and start answering those three questions.
Start at the top: Go to upper management, have your CTO or CIO to pull together a leadership meeting and rank what systems the business units use and what they think is needed first. Get them to look at the business overall and determine how much downtime is too much, how quickly do they want services recovered and how much data they are willing to lose.
When it comes to determining your internal SLA you do need to know what scenario you are planning for. Preparing for a riot that blocks access to your office is different than an earthquake that renders your data center a steaming pile of rubble. Ultimately, you want different plans for different scenarios, but if you must start somewhere, go with the worst case so you can cover all your bases.
But what if you can’t get leadership to sit down for this, or they want you to come to the table first with draft plan. Just GUESS.
Seriously, you have your hand on the data center, you know the primary goals of your business. If it was your company, what do you think you need to recover first? Use your gut to get you started. Look at your data center and pick out some of the key services that likely need to be recovered first to support the business needs. Domain controllers, encryption key management systems, infrastructure services like DNS and DHCP, communication tools and connectivity to the Internet might float to the top.
Sort the List: People want email right away? Great, that also needs an Internet connection and access to your authentication system, like Active Directory. People want the document management system or CRM or some in-house app with a database back-end? Fabulous, you need your SQL Servers and maybe the web front-end or the server that supports the client application.
Gather Your Tools: Look at your list of loosely ranked servers, devices and appliances and start building a shopping list of things you need to even start recovery. I always start with the “steaming pile of rubble” scenario, so my list starts like this:
- Contact information for hardware and software vendors
- Contact information and locations where my data center can function temporarily
- List of existing hardware and specifications that would need to be met or exceeded if ordering new equipment for recovery
- List of operating systems and other software, with version details and support documentation
- Names of the people in the company that would be crucial to the successful recovery of the data center
Type this all up. If any of the things listed above involve looking at a server or visiting a web page, remember that in the “pile-of-rubble” scenario you will likely not have access to those resources. Save it wherever you save this type of documentation. Then print out a copy and put it in a binder on your desk. Print out another copy, seal it in an envelope and take it home.
Congratulations! You are closer to a usable DR plan than you were before you started and we’ve just scratched the surface. Disaster Recovery planning is often pushed off until tomorrow. Whatever you have today, be it an outdated document from your company leadership, server documentation that is a year old, or NOTHING, you can take time each day to improve it. How you plan is going to depend on the needs of your organization and you won’t be able to complete the process in a silo, but you can get started.
I really enjoy disaster recovery planning. It’s challenging, it’s ever changing and I haven’t even mentioned how things like virtualization, Hyper-V Replica and Azure can be some of the tools you use. Stay tuned for more in the series about how some of those things can come into play. Sometimes the hardest part about disaster recovery planning is just getting started.