It’s a fairly innocent question that can send a DBA into a bit of a panic. Hopefully, the issue is not over the very existence of a disaster recovery (DR) plan. If that’s the case, then you need to address that problem as soon as possible. Unless your database is not of any business importance, there should be a validated disaster recovery procedure in place. The absence of a plan leaves you exposed to an extensive outage that can cause serious negative ramifications to your organization. So if you have a plan, have you tested it lately?
What Does a Valid Disaster Recovery Plan Encompass?
An effective DR plan is designed to recover the essential processes and functions that will allow your business to quickly rebound from an unexpected disaster scenario. This includes critical infrastructure and communication components of your computing environment as well as the databases and applications which they support. The plan should be updated periodically to include new equipment or software that your business needs to survive. Test and development systems are often excluded from a DR plan, as they are not critically important to the viability of your enterprise.
Disaster recovery is not to be confused here with high availability (HA). There are substantial differences between the two concepts. High availability concerns the efforts made to ensure that your database achieves 100% uptime. It is carried out through redundancy and employing components locally that can withstand errors without crippling the system.
A DR plan takes the ability to maintain your business-critical systems to the next level by enabling you to recover them in a different location. When your DR plan is activated it is due to circumstances that may have made high availability a secondary consideration for the moment. This can be due to unexpected weather events, fire or other reasons that force you to move your operation in order to keep your important business systems up and running.
There is a category of disasters that may impact an individual system and require you to activate a part of your plan in the location where the systems are usually housed. These are primarily caused by human error, such as inadvertently deleting a critical database. Procedures that are meant to address these situations also need to be tested.
Testing Your Disaster Recovery Plan
Having a disaster recovery plan is definitely a good step in protecting your business and its computing resources. But your plan is useless if it doesn’t work. The only way to verify that your DR plan will recover the intended systems and services is to test it. In 2018, a quarter of all business with a DR plan did not conduct any testing. This is unacceptable if your organization depends on its systems being available. Failure to test your plan is simply tempting fate.
Testing your DR plan is your best defense against unexpected disasters. Some components may be able to be tested in a stand-alone manner while others require a complete reconstruction of your computing facility. Best practices for testing your preparedness in the event of a disaster include these facets.
- Commit to regular testing, with a full test being run at least once a year. Based on the critical nature of the systems involved, you may want to perform these tests more frequently.
- Test the DR solution as well as the people who will carry out the plan. The human element is a critical component of your DR plan. Correctly identifying the best resources for conducting the test is an important task for management.
- Document the DR testing plan and outline the expected results prior to performing the test.
- Perform extensive documentation during the test. Reviewing the results of the test at its conclusion is a vital step in refining the plan and alleviating any problems with its execution.
- Keep your plan updated. The speed with which new technologies are introduced makes maintaining your DR plan a challenging task which cannot be overlooked. A plan that doesn’t change from year to year is probably obsolete.
Using Tools to Help Develop an SQL Disaster Recovery Plan
Developing a disaster recovery plan quickly becomes complicated and requires the use of various tools to ensure its viability. On one hand, project management software can be instrumental in ensuring the plan is comprehensive and covers all of the organization’ s critical systems.
There are also tools available to help DBAs and other application owners which can assist in identifying any technical issues that may negatively impact your chances of a successful recovery. They should be used to find issues with your recovery procedures with the intention of tightening them up before they need to be used in a crisis.
One such tool that can benefit SQL DBAs is SQL Doctor by IDERA. This comprehensive tool enables you to gain insight into the inner workings of your SQL system with an eye toward optimizing and improving performance. It also can identify SQL Server database integrity issues and problematic recovery procedures that can negatively impact a recovery attempt. This is critically important information which lets you address these problems before a DR test, or worse yet, a real disaster requires a recovery.
Hopefully, next time you are asked about the length of time since your last DR test, your answer will indicate that regular tests are occurring. Don’t wait until disaster strikes. Take proactive action to protect your company’s valuable digital assets.