I have been tasked with creating a document for the testing of our DR/BC Plan for our SQL Servers. We are using DB Mirroring (tier-1) and transaction log shipping (tier-2) and for tier-3 databases we will rely on nightly backups to restore too (non-critical DB's with little to none data changes).
What I am interested in is getting ideas on what should be in the document for testing the plan, I am wanting an accurate an detailed document that will test as many feasable scenarios as possible.
What I need to cover is the scenarios to test the three tiers (with more focus being on the top two tiers), which has very detailed step by step instructions on how to complete the scenario.
I have never done a document like this and would be interested in other peoples thoughts and experience.
- Is there examples for this type of document that I can look at?
- Has anyone had any experience in creating a document like this that would be happy to share thoughts and touch on what they included in there plan?
I have done application test cases before, do I aim for a document that is similar to a test case whereby an explanation of what you want to achieve and the steps that you do including specifying what gets typed, or should it be a more open document allowing the user to push the boundaries a little?
AS this is my first attempt and my searches on the internet hasnt returned much that is of any assistance, my appologies if I have upset anyone with silly questions or incorrect use of terminology, your guidance and corrections is appreciated.
Update: Basically, I am seeking any ideas or input into the best way to structure a SQL Server DR/BC Test failover plan to enable myself or others in the organisation to test our plans to ensure they work as intended. If anyone knows of any good resources they can direct me to it would be greatly appreciated.
Best Answer
I recommend keeping the document very simple and short so it is something that is easy to read, easily understood by people that are not experts in database technology and easy to update.
People have far better things to do than read long test plans, however the test plan should be detailed enough to be followed, its a tough process.
Based on this I believe the things that should be included in the test plan are:
preferably including links to scripts in source control and instructions on how to execute each test.
Other things may come to mind, but simplicity I think is key.
The only other thing that pops in my mind is while you may be writing a test plan for the database, don't forget that a live database that can't be reached by applications still does not meet business continuity objectives; though it may satisfy a data protection need.
Consider adding some minimal application testing to your plan or explicitly rule it out by mentioning what is In-Scope and what is Out-Of_Scope.