Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business
The most important information in most businesses can be found in the database. A lot of time and attention goes into planning for any new database application. Storage, servers, high availability, capacity, and clustering are just some of the considerations.
The same planning process must take place for disaster recovery and business continuity planning of databases. All actions taken to make business critical applications available must be methodical and deliberate. Disruptions are serious events and should not be taken lightly. "It's not about seeing the [recovered] data on your screen, but conducting business." (Day, Jo, Day, Kevin, 2006) Databases that are at the heart of the business today fall squarely on the critical path of the disaster recovery actions taken when a disruption strikes.
Partial or complete disruptions of a business can be devastating. Business continuity planning can ensure that capacity is available for critical business operations in the time of need. Practiced professionals in the area of business continuity understand that life and opportunities can continue after a disaster. Understanding the steps involved with keeping a business viable is where some planning is needed.
One of the first things needed are the requirements for each database supported. Recovery times are probably the most important of these requirements. The difference between a few seconds of downtime and a few minutes of downtime can be quite substantial. Some business units may have a tolerance for a few hours. This must be known for each database for your plan to be effective. "...you have to prioritize what you need in order to function... you have to figure out what is actually mission-critical." (O'Hanlon, 2007)
Another important answer needed is in reference to data loss. If little to no data loss is acceptable, then a disaster recovery solution can become a budgetary concern. If the backup from last night will suffice, then this can lead to major cost savings.
Capacity can be a concern at the disaster recovery site. Customers should be asked about performance degradation and what is acceptable. This can be a tricky question to answer, and customers will usually need assistance to figure it out. If left to themselves, they will almost always answer that no degradation is acceptable.
Another question that should accompany performance degradation is finding out about the number of users that will be accessing the system during the disruption. These two answers will help to identify a more accurate capacity. What should be explained is that during the disruption, the entire corporate population may not need access to the enterprise application. Possibly only power users may need the system to run business critical functions for the enterprise.
One example is Human Resources applications. An HR application may be available to the corporate population during normal operations for viewing pay stubs, updating W-2s, etc. During a disruptive event, these rights could be suspended but power users could continue to run payrolls, enter benefits, hire and fire employees, etc. It is possible far less capacity is needed than originally thought necessary, which can mean more databases on the same servers, as long as the databases will not interfere with one another's processing. Virtual servers can be used as well, "... you would re-instantiate the virtual machines at a higher ratio (density) of virtual-to-physical. Consequently, organizations that can tolerate a slight drop in performance can build a much cheaper secondary data center to handle temporary disruptions." (Antonopoulos, 2006)
Accessing the databases and applications is another important matter. If the primary place of employment is no longer habitable, employees will need a place to go for office space and workstations. Workstations will need to be equipped with necessary software for database connections. This important point must not be overlooked.
Testing is very important. Determine the frequency in which you will need to test your disaster recovery plans. Only through testing of the plan can issues and problems be discovered and corrected. Testing can also bring opportunities to make improvements to the disaster recovery plan. "Disaster recovery (DR) testing isn't about pass and fail. It's about exercising and rehearsing the DR plan to reveal shortcomings and weaknesses." (Gsoedl, 2006)
Since nothing stays the same in business very long, you will find the same quality in disaster recovery plans. To keep them relevant and up-to-date, testing must become a regular occurrence. Testing may occur yearly, twice per year, or quarterly. The more practical experience individuals can get with the disaster recovery plan and the disaster recovery site, the better off everyone will be during a crisis situation. Familiarity will build confidence in individuals and the equipment and systems they are working on.
Usually, disaster recovery setup is not an emergency. The emergency only comes during execution of the plan. Still, a timeline should be put in place when planning disaster recovery for databases. It is unfortunate that many times, other projects push disaster recovery to the back burner. Make disaster recovery part of all projects so that it can be completed in a timely manner.
Moving back to the primary site will be a joyful time. It can also be quite hectic. "... you should plan to get back into your own premises as fast as possible" (Dawson, 2007). No one wants to stay at the disaster recovery site any longer that they have to. Plan the return much as would be done with the go-live of a new application. Plan the downtime, migrations, testing, go/no-go decision and fallback procedures. Everything should be scheduled and users made fully aware of the outages and change over schedules.
There is someone, or some people, in the organization that will make the decision that a disaster has struck and failover should now take place. Determine who that person is and how the information will be communicated. Ideally, the information will be distributed in multiple forms. Rarely in a disaster will all the normal lines of communication be available to the organization.
Antonopoulos, Andreas M. (2006). New Data Center Strategies. Network World. http://www.nemertes.com/columns/virtual_machines_help_with_disaster_recovery. Dawson, Sam (2007). What is Disaster Recovery? British Journal of Administrative Management. Issue 57. Day, Jo, Day, Kevin (2006). Test Drive Your Disaster Recovery Plan. Journal of Financial Planning. Supplement. Gsoedl, Jacob (2006). Disaster recovery: Test, test and test some more. Storage Magazine. http://searchstorage.techtarget.com/magazineFeature/0,296894,sid5_gci1258315_idx1,00.html. O'Hanlon, Charlene (2007). Courting Disaster.T H E Journal. Vol. 34 Issue 9.
About the Author
Kevin Medlin has been administering, supporting, and developing in a variety of industries including energy, retail, insurance and government since 1997. He is currently a DBA supporting Oracle and SQL Server, and is Oracle certified in versions 8 through 10g. He received his graduate certificate in Storage Area Networks from Regis University and he will be completing his MS in Technology Systems from East Carolina University in 2008. When he's not trying to make the world a better place through IT, he enjoys spending time with his family, traveling, hanging out by the pool, riding horses, hiking, and camping.
This article was first published on EnterpriseITPlanet.com.