A FIRE ERUPTS in the middle of the night in your enterprise’s warehouse that quickly spreads to the server room just a few walls away. Although the local fire department arrives in less than 10 minutes and quickly extinguishes the flames, the data center’s entire cooling and power infrastructure is destroyed, along with several mission-critical servers. The data center will not be operational again for several weeks.
At the start of the following business day, there are no working servers with which to take and send orders, meaning the enterprise will no longer be able to generate revenue. In the IT department, nobody seems to know how the backup systems work or even where the backed-up data and applications are. The CTO knows that a disaster recovery plan was completed a few years ago but is unfamiliar with the specifics, and the person who set up the plan is mountain-climbing in Tibet and is not reachable by phone or email. The scenario is frightening, but unfortunately, it is all too representative of what can happen when disaster strikes.
Here are some ways to better plan for disaster recovery so that if the worst does happen, your enterprise’s server applications can be back up and running quickly.
Prioritize & Organize
The importance of applications and data varies, so disaster recovery planning should likewise prioritize what gets recovered first in the event of a disaster. If you have 10 servers, there might be three that are mission-critical that everyone needs to do their job all day long. But some servers might be less important, so that if you turn them off, nobody would notice for a few days.
Prioritizing should involve gathering input from people outside of the IT department. Instead of getting the email server to work first, the executive knows that the impact if the calendar is unavailable is more significant. That is why it is important to have the input from everybody in the different departments to prioritize so everybody understands what is important.
Remember, too, that the best disaster recovery plan is not much good if only one person has everything in his or her head and is missing on the day things go wrong. That is why it is essential to make sure that plans are widely documented and that pertinent information is readily available. Even make sure that you have cheat sheets printed out in hard copies with important contact details and escalation procedures that IT [staffers] have and keep in their wallets. The IT staff also needs to know whom to contact, so whether it is different technical, facility, [or] data center providers, etc., you need to know.
Carefully Plan Backups & Management
Admins are constantly assessing data center and network capacity needs, but don’t forget to adjust the capacities needed for adequate backups as part of disaster recovery planning. It is not an either/or model, because you have to think about planning in such a way that integrates your data center’s data and applications with the backups. For that matter, any capacity improvements should improve disaster recovery, as well. Plans must also cover strategies for any office, regardless of location. At the same time, disaster recovery plans should also involve drawing on admins from locations offsite on an as-needed basis to manage other data center locations remotely in the event of a disaster. However, having too many people doing too many things can also cause problems in the event of a disaster.
You don’t want to have too much help in certain areas that can cause it to be more chaotic. To combat having too many cooks in the proverbial kitchen, admins should clearly outline who does what in their disaster recovery plans. You need to outline what staffers need and can do and clearly outline whom you need to contact to get approval from before you start. It is also necessary to spell out what IT staffers should not do. Somebody from the security team might try to figure out how to get a Web site switched over but who doesn’t know all of the ins and outs and details. Instead, you have to make sure the security team, Web [management teams], and facility groups know what they are supposed to do and what they are not supposed to do. They need to know the boundaries.
Don’t Forget About The Business:
Given the technology options from which admins can choose to recover from a disaster, it might be easy to forget that disaster recovery planning must ultimately serve the enterprise’s business needs first. Today, IT infrastructure is undergoing radical change as a result of virtualization, cloud computing, globalization of customer markets, and supply chain; however, the fundamentals of business continuity and disaster recovery are still the same.
The most basic principle is that disaster recovery covers not only technology, but the services a business relies on and provides. It’s about the resiliency of those services, and it includes people, processes, and the whole supply chain. Every organization needs to be aware of its own ability to recover from a business interruption and also be aware of the capabilities of its suppliers, including any cloud service, software-as-a-service, or platform-as-aservice providers.
So although disaster recovery solutions continue to evolve, the fundamental questions remain the same for disaster recovery planning. For example, disaster recovery planning must ensure that the organization knows which processes and applications are mission-critical and how quickly mission-critical processes and applications can be restored. Proper planning also should involve assessing potential business impacts of interruption and making sure IT admins and business leaders close any gaps between their recovery needs and their recovery capabilities.
Key Points
- Disaster recovery planning should be an ongoing and constantly evolving process. Finalizing plans and then waiting for a disasterto happen is not recommended.
- A disaster recovery plan is only as good as the document that staffers must use and rely on in the event of a disaster.
- Planning should prioritize quick restoration of applications and data that users require with less emphasis on nonessential systems.
Go Active-Active:
Once the perfect plan is in place, many might think it is OK to step down and move on to another project while hoping for the best if and when disaster strikes. This wait-and-see approach is knows as a “passive-active” process. Instead, planning for disaster should be an ongoing process, which is an “active-active” planning. Continually making sure that disaster recovery plans are ready to be executed at any time is an ‘active-active’ approach. Whether enterprises have their own site or whether they take advantage of hosted opportunities, active-active is viable regardless of the size of the enterprise.
