Creating a Disaster Recovery plan is more than just having database backups which satisfy the Recpvery Point Objective (RPO).   Analysis is required of business downtime causes and  what are the consequences of downtime.

In an earlier post Powershell and disaster recovery planning , I outlined some of the benefits and techniques of using Powershell and SQL Server in Disaster Recovery Planning.    There are many aspects to database server disaster recovery planning – including: backup storage  and location,  rebuild documentation, installation media, rebuild scripts, DNS and cnames , escalation process and security details

The high-level steps to creating a Disaster Recovery Plan are

Step 1: Perform a Business Impact Analysis - Tier recovery data into order of importance.

Step 2: Perform a Risk Assessment - Identify potential points of failure.Read up on Decrease database risk

Step 3: Manage Your Risks - Put solutions into place to manage your risks.

As a DBA, Disaster Recovery planning is fundamental to preserving business continuity. Database servers are key repositories of permanent data covering all aspects of an organization. Lots of work has probably gone into defining RPO and RTO, but here are some other considerations for the DBA.

1)    Have you tested the backup plan? I don’t just mean checking the backup reports but do you have a regular test plan for restoring different types of databases. ?

2)    Have you submitted your up to date disaster recovery documentation to an offsite repository?

3)    Have you tested your disaster recovery plan?

4)    Do you have contingency plans for different scenarios , such as server failure, unplanned database delete?

5)  Level of redundnacy built into your architecture - read Redundancy for SQL Server