SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


A Simple DR Solution


A Simple DR Solution

Author
Message
Wayne West
Wayne West
SSCrazy Eights
SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)

Group: General Forum Members
Points: 8220 Visits: 3702
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
alen teplitsky
alen teplitsky
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11132 Visits: 4674
for our apps we use db's and tables that are populated with usernames, server, db, login and password

app starts up and checks the db and table for the credentials it will use to access sql. this way all we have to do is make a few changes to point apps to another server
Nicole Bowman
Nicole Bowman
Mr or Mrs. 500
Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)Mr or Mrs. 500 (579 reputation)

Group: General Forum Members
Points: 579 Visits: 1615
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.

Nicole Bowman

Nothing is forever.
Wayne West
Wayne West
SSCrazy Eights
SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)SSCrazy Eights (8.2K reputation)

Group: General Forum Members
Points: 8220 Visits: 3702
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? BigGrin 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
Caleb-142520
Caleb-142520
Valued Member
Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)

Group: General Forum Members
Points: 66 Visits: 196
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 Smile

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
mops33
mops33
SSC Rookie
SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)SSC Rookie (26 reputation)

Group: General Forum Members
Points: 26 Visits: 169
Nicole
as 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.



alen teplitsky
alen teplitsky
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11132 Visits: 4674
here is a solution for jobs

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.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search