I have worked on large and small DR projects for SQL Server. The very best/coolest was using SRDF/A on Symmetrix and Windows 2003 Cluster. The smallest being transactional replication. SRDF technology had my disks waiting for me at the DR Data Center 1200 miles away over DS3 and all I needed to do was script the unlocking of the disks, running of two batch files and the cluadmin up the cluster and we were live in 5 minutes 🙂

No matter what type though, there is one thing for certain: the business generally has a very good clue about what they want but they can't describe it, and my job has been to edumicate them. If I don't get them up to speed, who will? Even some server admins who work on advanced projects and are certainly not ignorant dudes, miss the boat on SQL Server DR. It's funny to joke around about, but it won't be when "it" happens. And I've seen "it" at least once with a data center fire that cost a few million but didn't kill the company (25B, large undisclosed company).

One of the biggest misconceptions is the living state of the mdf/log files and the fact that flat file backups of the NT system don't cut it for recovery. Many folks believe they are covered because they backup the server OS, including all the data volumes and log volumes that SQL Server lives on. Not the case. While flat file backups or .BK files that are caught in the NT backup will recover the server to a point-in-time, that may not be sufficient for what the business needs. Worse, if the NT backup is missing the window, you may be a day late (NT 8PM, SQL 10PM etc..).

My approach has been to tackle it at a high level as such:

1. Determine the Business Recovery Requirement

2. Explain Existing Recovery Capabilities to biz

3. Explain Existing Risk to biz

4. Match Requirement to Existing Recovery Capability

5. Have biz sign-off on the documented risk level they are willing to accept

6. Implement a disaster recovery that will CYA beyond the minimum the business signed-off on

7. Pray that you aren't the guy who tells the bad story of his DR setup failing and who is looking for a job in this forum.

And lastly, remember to be the guy bugging your boss about disk, DR, backups and your needs. Gripe and fuss and do it in e-mail on the phone, through chat. That way, when you saved the day by the hair of your chinny-chin-chin, you can tell them that having you on staff saved them all the money they would need to have spent, should a DBA who implemented CYA not been hired, on products that actually do guarantee business continuity by hiring you and keeping you employed during an economic slowdown.

-Cal