Very good article for a basic intro to DR and some of the pitfalls that you could encounter. You're describing a higher level of DR than we're employing at this time, though we're working towards a higher level. Unfortunately right now all we have is our backups going to a building a mile away. If we lost the server room to a fire or whatever, we wouldn't have much data loss, though there'd be a LOT of purchase orders issued the next day for new hardware!

Fortunately our ERP system SFTP's itself to the vendor on the east coast every night, so that system can still be productive if a disaster happens. They were able to cut paychecks for a city hall that was wiped off the map by Katrina and couriered them to the nearest city with an open bank. It may not be perfect DR, but it's good enough.

-----Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson

Nicole Bowman (7/31/2008)Thanks for a clear and concise article. It made me realise that there is some work to do here! The backups are good but the jobs, DTS packages and logins aren't very well covered.

Jobs and DTS packages are stored in MSDB: you are backing up your system databases, aren't you? :D Under 2000, you can also script out your jobs, very handy for copying standardized maintenance (DBCCs, system DB backups) between servers. You can script them out in 2005, but in 2000, you can do them all at once. Or at least if you can do them all at once in 2005, I haven't found it yet.

As a part of my EOM/first of the month processing, I script out all databases, and then in separate runs, I script out the logins and jobs. If an object accidentally gets deleted, it gives me a fallback. If we had a CVS system, I'd be checking it in there so I could run deltas between months and see if anyone is mucking with my systems that I don't know about.

-----Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson

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 Requirement2. Explain Existing Recovery Capabilities to biz3. Explain Existing Risk to biz4. Match Requirement to Existing Recovery Capability5. Have biz sign-off on the documented risk level they are willing to accept6. Implement a disaster recovery that will CYA beyond the minimum the business signed-off on7. 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.

Nicoleas far as DTS/SSIS goes, we use DTSBackup2000. We execute an overnight batch of the command line exe to copy all server-based DTS packages to the DR site. We also decided early on that all SSIS packages should be file based.All file-based DTS and SSIS packages are xcopied to the DR site in a separate script.

Logins are also scripted out, including IDs and hashed passwords, and sent to DR overnight.

Agent jobs are somewhat problematic in that they are copied manually on creation. We haven't pursued this much more since our set of jobs is fairly static.

we have some dev sql servers where the developers make their own sp's and keep there. rule is that anytime someone wants a new copy of a db we restore from backup because it's too much to copy over the data. sometimes the devs forget to back up their stuff because we don't backup dev and qa.

i had an idea to make a sql server with blank db's with the same names as prod and copy all jobs and sp's there for backup.