December 22, 2006 at 10:52 am
OK, here's my understanding of using SAN backups to recover from a disaster.
- SAN takes backup of database files (.mdf, .ldf, .trn)
- the SAN array can be attached to the standby server and the files backed up above can be used to attach a database to a SQL server instance and restore up to a point in time
Is this better than using log-shipping? If so, we want to evaluate whether or not to discontinue log-shipping. Thanks.
Chris
December 22, 2006 at 11:02 am
YOu'd have to talk to the hardware guys to verify everything, but you absolutely CAN take one server and hook it up to a SAN after another server crashes. The caveat, of course, is having an OS and all the necessary software / network bits set up on the new server.
A SAN actually has its own set of disk controllers and is connect to a single server or a cluster via a separate NIC (network card) on a fiber link. It's not quite plug-n-play but it works almost as effectively.
SANs are used for more than disaster recovery scenarios, not used for moving data. It doesn't replace Log Shipping if you are doing LS for a report server, etc. However, if you're using LS as a DR solution, then yes, you can replace it with a SAN. I do recommend clustering in addition to a SAN, though, because it's only a hardware solution for DR or database performance / storage issues.
December 22, 2006 at 11:05 am
I'd seriously suggest you rely upon sql backups. I've used sql server on SAN's for around 5 years and have always used sql backups. There's some useful white papers available on the Hitachi website, hds.com , I can't find the exact link, unlike some other vendors HDS publish a number of useful documents, you might also want to check out http://www.snia.org and there is some microsoft documentation, but not a lot just now.
I don't want to appear rude but a lot of claims are made for SAN's, probably by the marketing departments, and some postings here are probably made without benfit of experience, sorry!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
December 23, 2006 at 12:18 pm
I really appreciate everyone's responses, thus far.
The log-shipping is purely for maintaining a warm standby server. So, using the SAN can eliminate the need for this, right?
Colin, I understand your point, as well. To start with, I think that we'll rely on both the SAN backups and the native SQL server backups.
Let me know if I am missing something, please. Thanks.
Chris
December 28, 2006 at 1:06 pm
If you rely on snapshot backups to replace log shipping you may be sadly disappointed in the event of a failure. Remember log shipping also allows you to restore to a specific point in time, although I guess as long as you get tran log backups you might be ok. Just draw out on paper the various scenarios that you may need to recover from and then figure out all that can go wrong , how you'd recover it and then test it to see if it's right. ( Take into consideration hardware failure, malicious damage etc. etc. - remember the storage units in a SAN could still fail as could the fabric which supports it - consider such obscure issues as theft of the disk drives , a spilt cup of coffee - it only takes two disks to fail in a raid 5 ( three in a raid 6 ) and you can kiss goodbye to all your data - I'm pretty sure there's some good articles about DR etc. on the site )
A snapshot is fine for a static non working database, in effect it's similar to pausing the sql server, now it's possible that at the point of snap a transaction has not finished being written ( COW ) should you then use your snapshot the database would be in an inconsistant state( which means it goes grey ! )
I had a discussion previously on a ms forum similar to this subject matter regarding san replication for DR, in the test some of the sql databases became unavailable, and that was a controlled failure - yeah it's a strange way to put it but I'm sure you know what I mean!!
Good luck.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
December 28, 2006 at 3:22 pm
Excellent advise, everyone! Thank you VERY much!
Chris
December 28, 2006 at 4:05 pm
Thanks guys, its been very informative. Seems like most of us rely on the native SQL server backups more than the SAN based snapshots.
This is very interesting cuz it puts in a new dimension to why we had SAN in the first place.
Anyway, Back onto my original question - My vendor exact response is as follows:
"you cannot do a conventional backup of the db that is being managed by SMSQL, as there can only be one application that is rolling the logs.
If you want to take a tape backup of the db, create a clone volume, then do a normal ntfs backup."
So, now I've set up a different server where we're snapmirroring and then taking backups.
However, they havn't convinced me yet. What do you think?
January 2, 2007 at 8:04 am
I think you should test this. Create a job that does a few daily backups via the traditional SQL Server method, but backs up to the SAN drive. Tack on a few transaction logs just for kicks and giggles (once an hour or once every couple of hours).
Once you have a few, try restoring to a brand new database. Does it work? If so, I think you're set. Then all you have to worry about is getting the tape drive to back up the appropriate SAN drive so you have multiple copies of your database backups. One on the server and another on your tape backup of the drive.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply