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.
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.