January 11, 2012 at 5:47 am
One of our customers has requested to setup a Disaster recovery site..
Their motive is just to cover up for some auditing and must be demonstrated only twice in a year..
Which high availability is the best to use in this scenario?
We will have to make sure to use minimal resources.
January 11, 2012 at 8:09 am
This is a rather large and open question (really more information is needed to more accurately answer your question)...What is the customer's SLA on downtime? What kinds of things need to be backed up?
If you just need to back up the DB's (and they are currently in FULL recovery mode) you can set up logshipping to a DR site/server, if you have to backup SQL Agent jobs (which include SSIS jobs) you'll need to script some things out...
Can you please be more specific?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
January 11, 2012 at 8:15 am
Their motive is just to cover up for some auditing and must be demonstrated only twice in a year..
It's not a good reason for DR solution.
January 11, 2012 at 8:15 am
The DR should be up within 24 hours after the disaster...
January 11, 2012 at 8:22 am
Please be more specific:
1) What's an "acceptable" amount of lost data? i.e. Anything since the last full backup? 2 hours of data? 6 hour? NONE?
2) What recovery modes are currently being used in this environment?
3) Is this DR-scenario for a transactional-based enviornment or just for historical data (i.e a datawarehouse)?
4) What dependencies/gotchas exist?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
January 11, 2012 at 8:22 am
Consider:
Clustering - Provide failover to another server should the active server running the database fail (not including SAN). This is not a full DR solution (unless you have a mirrored SAN offsite with associated 2nd cluster).
http://www.sql-server-performance.com/2002/clustering-intro/
Log shipping - Can be onsite, offsite and the latency is fully configurable and dependent on bandwidth
http://www.sql-server-performance.com/2002/log-shipping-70/
Mirroring - similar benefits to log shipping but much easier to configure. Requires SQL 2005 and later.
http://technet.microsoft.com/en-us/library/cc917680.aspx
...also consider replication..
Robert Murphy
January 11, 2012 at 8:31 am
MyDoggieJessie (1/11/2012)
Please be more specific:1) What's an "acceptable" amount of lost data? i.e. Anything since the last full backup? 2 hours of data? 6 hour? NONE?
2) What recovery modes are currently being used in this environment?
3) Is this DR-scenario for a transactional-based enviornment or just for historical data (i.e a datawarehouse)?
4) What dependencies/gotchas exist?
I am sorry..I didn't have much info about a lot of these questions...
1 - Data loss is not appreciated..Hardly a couple of hours of data should be ok
2 - Full recovery models
3 - Definitely transactional based environment
4 - I didn't understand this?
January 11, 2012 at 11:07 am
1 - Data loss is not appreciated..Hardly a couple of hours of data should be ok
2 - Full recovery models
3 - Definitely transactional based environment
4 - I didn't understand this?
Sounds like logshipping would suffice for this type of scenario, and as rob has already pointed out, there are a couple other options. IMHO, the log shipping is probably the easiest to set up and get going.
What I meant by #4 was if there were things like SSIS packages that perform ETL-like processes or Custom scripts, SQL Agent jobs, specific applications running on the existing DB server, and etc that you would need to take into consideration to have mirrored on the DR box - youo'd need to take that into consideration
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
January 11, 2012 at 11:42 am
Hi Benki,
I think there are a few things that you may be missing on the answers that everyone has provided to you. I hope this answer helps you.
There is a ton of potential answers to your question, we could talk about RAID levels, and how that is a DR solution for a bad disk. We could talk about hot sites, or cold sites. A DR solution has to be driven by the requirements that your customer has. You are going to have to sit down with them and help them answer the questions to make sure that it meets their requirements. Many clients are not going to understand some of the questions that you need to have answered. Things like acceptable data loss, acceptable recovery time, hot or cold site, or do you even need a DR Site.
I would recommend a multiple step approach, give them an example and ask them what they would like to have done, and what they must have done to not impact the revenue to their company. Base on the answers then you can begin with the next level of requirements gathering. Your messaged stated this was for an audit requirement. What is it?
If its for Audit Only and it has to be practiced every 6 months, then does a backup and restore of the databases meet the requirements? That is a very valid DR solution.
October 17, 2013 at 6:48 am
Benki Chendu (1/11/2012)
One of our customers has requested to setup a Disaster recovery site..Their motive is just to cover up for some auditing and must be demonstrated only twice in a year..
Which high availability is the best to use in this scenario?
We will have to make sure to use minimal resources.
'Site' implies should you lose your building and hardware, how would you get up and running?
This is a lot more than just proving you can restore a couple backups.
And does conflict with minimal resources, as it would involve additional hardware and physical location, etc.
You need to get a much clearer picture of what is truly being expected to research your options.
And be sure to take into account your physical / virtual machines, hardware, and processes today.
January 31, 2014 at 3:37 pm
You also need a strategy/process for syncing up database logins between the two sites.
And if you use SQL logins, then you need scripts/processes that sync up the database users associated with those logins because of the different SIDs.
That said, Mirroring or log shipping are the obvious candidates.
You need to get detailed information on what the actual SLAs are with respect to down-time and data-loss.
You do not want to start designing your solution before you have all the requirements.
January 31, 2014 at 3:58 pm
@arnipetursson +1 - The logins/SIDS completely slipped my mind, but shouldn't pose much of an issue considering they would physically be available to the DR site, you'd just need to "correct" them
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply