Disaster Recovery: Defining Your Top Priorities

Disaster recovery scenario: Your servers are all inoperable. The computer room is dark. A major catastrophe has occurred and you need to determine your next steps. What are your priorities? What should you do first? In which order should you begin your server recovery? Everything is a business priority, according to the business experts. Quick, lock the doors because a mad dash of self proclaimed experts is about to come bursting into the computer room and start barking out orders.

Are you going to listen to the person with the loudest bark and get his server back up and running first? If not, what IS your top priority? The computer systems may or may not be recoverable immediately. Maybe they won't be available longer term either. You take a deep breath and tell yourself this is what we have been documenting and practicing for all these years. But does your current disaster recovery plan include prioritization of servers in a disaster?

Managing Mission Critical Servers for Business Continuity
There is a lot of work that goes into managing the on-going requirements for mission critical servers. When you have downtime, whatever the cause, data is unavailable to your customers, and this usually means that business - for you, your customers, or both - simply stops. When this happens, it gets very expensive in a hurry. That is why critical server requirements should be reviewed twice a year to ensure that effective server processes are being carried out to support the true needs of the business and that these identified servers are still in alignment with business goals and priorities. Listed below are the elements that should be reviewed frequently to support the requirements for critical servers in your business.
• Business impact analysis and risk assessment
• Strategy for server recovery
• Change in prioritization based on different business cycles
• Application dependencies and interdependencies
• Application downtime considerations for planned and unplanned outages
• Backup procedures
• Offsite storage for vital records
• Data retention policies
• Recovery time objectives (RTO)
• Recovery point objectives (RPO )
• Hardware for critical server recovery
• Alternate recovery site selection
• IT and business management signoff

Classifying Systems for Disaster Recovery Priority
When you walk into the computer room you may be overwhelmed with rows and rows of servers. Various hardware platforms are powered on and ready to serve some business purpose. Typically the servers span several hardware generations. What’s essential is a planned roadmap and prioritized recovery plan of your complete critical server infrastructure. You need to know the supporting business needs of all servers before disaster strikes. Don’t wait for that phone call in the middle of the night to decide your server recovery strategy. All the servers that reside in your computer room are not equal in level of importance to your business. That is why you need to take into account the difference between:
· what you need
· what you want to have
· what you don’t need at all to run your business in a disaster.

Your backup recovery team should assign server priorities as they relate to your business support priorities. There will be a mix of opinions, of course, but a good Business Impact Analysis will reveal which of those opinions carry the most weight. You should categorize the business requirements and supporting servers as Critical, Essential, Necessary, or Optional, as follows;
· Critical Systems - These servers must absolutely be available for any business process to continue at all. These systems have a significant financial impact on the viability of your organization. Extended loss of these servers will cause a long term disruption to the business, and potentially cause legal and financial ramifications. These should be on the A-List of your disaster recovery strategy.
· Essential Systems - These servers must be working properly to support day-to-day operations and are very often integrated with Critical Systems. These systems play an important role in delivering your business solution. These should also be on the A-List recovery strategy.
· Necessary Systems - These servers contribute to improved business operations and provide improved productivity for employees. However, they are not mandatory at a time of disaster. These might include business forecasting tools, reporting, or maybe improvement tools utilized by the business. In other words, minimal business or financial impact. The targeted systems can be easily restored as part of the B-List recovery strategy.
· Optional Systems - These servers may or may not enhance the productivity of your organization. Optional systems may include test systems, archived or historical data, company Intranet and non-essential complementary products. These servers can be excluded from your recovery strategy.

These server classifications will provide you with the baseline for your decision making matrix. The key is your IT recovery team and your business management team must agree with the disaster recovery planning scope for classifications of the servers. By differentiating between critical, essential, necessary and optional, the reduction in the number of servers needed to support the disaster recovery plan not only helps increase backup and recovery efficiency for the servers, but it also helps reduce your financial budget for disaster recovery.

The Big Picture
When compiling the list of mission critical applications, you must also consider application interdependencies. First, many software solutions are considered modular in design yet the software must be 100 percent intact -- in other words, fully restored to function correctly. You cannot break the applications apart from the supporting infrastructure for the server. You may choose not to make use of specific business functions, but the entire solution must be rebuilt completely in order to function properly.

Second, consider the flow of information. Follow the flow of a transaction from initial order to product delivery. You may find that a server not considered critical by the Business Impact Analysis does in fact have a significant role in feeding information back to another identified mission critical application. Therefore, IT input is necessary in addition to the defined business needs. The restoration process for most servers is typically recovered in its entirety which includes every user library saved on the system. The question then becomes, are you restoring too much? Omitting non-critical libraries can save hours, which translates to the business coming online more quickly in a disaster. The libraries and user directories that could feasibly be omitted include:
• Performances data
• Audit journals
• Test libraries
• ERP walk-through libraries
• Online education
• Developer libraries
• User test environments
• Data archives
• EDI successful transmission objects
• Trial software
• Temporary product work directories
• Auxiliary Storage Pools (ASP s)
• Independent Auxiliary Storage Pools (IASP )

Required Hardware for Your Disaster Recovery Plan
In the development of every disaster recovery plan, you must determine the minimum hardware requirements for your mission critical servers. Some IT professionals will say that any equipment is better than none in a disaster.
This statement should not be accepted at face value. The real story is, only mission-critical applications absolutely need to be restored in a disaster, not everything. However, you will need to ask if your business will accept running the “Mission Critical “ business functions at say 50 percent less capacity or throughput. In most cases, the answer will be no -- totally unacceptable.

In your Business Impact Analysis you identified the financial impacts for your organization of being down for an extended time period. Running your business at half speed will only further impede your long term business capabilities and will likely hurt customer satisfaction. You would do well to reduce the disaster recovery risk by eliminating non-essential applications rather than providing less processing capabilities. Invest your disaster recovery budget wisely by sustaining your business requirements in a disaster, which means selecting the right hardware. The last thing you want to happen is for your sales desk to tell customers you can only process half the orders right now because we had a disaster and we are still working things out.

The Human Element
What if you declared a disaster and your team did not show? Your servers can’t recover by themselves. Many companies have plans that address their equipment requirements and recovery processes but will underestimate the amount of personnel required to successfully execute their plan. Equipment only works if a qualified person is able to operate it. In Gulf coast hurricanes, key personnel have sometimes been displaced or unavailable due to health risks or personal priorities. When regional disasters hit, transportation within the area can be challenging and may result in personnel being unable to reach their assigned locations. Equipment may be accessible, but it will be ineffective if your staff cannot access the recovery site. What is the level of expertise your employees possess when they actually do reach the recovery site? Too many companies, especially those that perform recovery tests with no more than their data center staff, often count on IT heroics to pull them out of a crisis. Expecting IT to perform a miracle in an emergency is difficult for your staff and avoidable today when full recovery tests can be performed without impacting your production users. If your disaster recovery plan includes cross departmental staffing, it is important to have precise and detailed documentation. Companies should create recovery documentation so that anyone in the business, from the shipping manager to the CFO, can start a recovery. In a well-tested plan, an employee from another department should be able to start the recovery in the event that employees from your IT staff are not on hand. You may never know if all your key personnel will be able to assist with the recovery. After identifying your critical equipment, it is advisable to test your disaster recovery plan with a subgroup of assigned individuals while leaving the rest of the team to run normal business operations. The success or failure will be a good measure of your corporate readiness.

Summary
When the servers are down, your disaster recovery plan will determine the precise server recovery strategy and recovery priorities. So, lock the doors to keep the stampeding herd of users away. Fire up the iPod, plug in your earphones, and start recovering the business as stated in the plan. Step through the tasks and follow the exact order of server recovery by predetermined importance criteria versus listening to the loudest screams. And take the time required to do it right.

Article Source: http://casinoarticles.us

About the Author Richard Dolewski is a certified systems integration specialist and disaster recovery planner. As Chief Technology Officer and Vice President of Business Continuity Services for WTS (www.wts.com/disasterrecovery.asp) he has extensive experience in disaster recovery planning, backup and recovery program design, and high availability solutions. His recent book, System i Disaster Recovery Planning, is available on-line at amazon.com.

Please Rate this Article

5 out of 54 out of 53 out of 52 out of 51 out of 5 

Not yet Rated