March 30, 2009 at 2:06 pm
Hi All,
I have been looking into an environment where they use Netapp SnapMirror to replicate the SAN volumes. They are NOT using the NetAapp SnapManager for SQL server which in turn uses the Volume Shadow Copy Service . The assumemption that the DR solution works although they are just doing a SAN level Volume copy. My gut feeling is that SQL Server will not bring the database up in the DR site. So my question is more clear , is a SAN level snapshot without using the Volume Shadow Copy Service is a proven or Is a proven or effective DR solution ?
TIA
regards
YeePee
July 27, 2009 at 7:45 am
.
July 27, 2009 at 8:49 am
No idea, and while you can ask the vendor, I think you'd have to test this exhaustively. There are some new technologies that might make this work.
One note is that SQL won't be aware of the copy, so it's possible you could have large, uncommitted transactions when the copy occurs. If so, you'll have a rollback when things startup.
July 28, 2009 at 3:31 pm
I worked for several years in a shop that used Net Apps for their SAN.
There are other issues here that you may need to look at when you are trying to use this type of SNAP technology.
1. If your Data Files and Log files are on seperate LUNs you lose the ability to have your SNAP have the same LSNs in the Data file an Log file. This is due to the fact they are not Snapped at the same moment in time. Remember a SQL database requires both data and log files to be in sync to beable to recover without any data loss.
2. Using SNAPS for your disaster recovery will mean that you can not use any TLog backups to restore any transactions beyond the point of the SNAP. ( The steps you would take in recovery would be to attach the mdf/ldf files, when you do this SQL recovers the database, leaving you no options available to restore the tlog backups.) I have found that in most cases that if the data is important enough to be in a disaster recovery plan that it usually must be transactionally close to current as well.
My suggestion to most clients is to use Mirroring or Replication to your DR sites. That way SQL can assure the ACID compliance is maintained.
July 29, 2009 at 2:42 am
I work for a global company that uses Netapp SAN technologies and having the VSCS is an extra level of protection. As long as you have snapshot to restore to it's not a problem. We have an agreement we can restore back to the last 20 mins as TL backups are running 3 times an hr and a couple of full dailies. I would definitaley recommend this technology as opposed to mirroring if you can afford it. Nettapp have a piece of software called SnapManager for SQL which easy to use and works well for us. It's also a good idea to have your LDF's and MDF's on separate LUN's to reduce perfomance cost, this is a nettapp best practice. hope this helps
July 29, 2009 at 6:10 am
I have experience of a similar situation but using HDS kit.
It can work very well providing the data and log volumes are in the same synchronisation set. In HDS it is possible to configure multiple LUNs so they are treated as a unit for snapping.
I have no idea if this is possible with NetApp. Bobbu has given the right advice that you need to get this aspect right, or you risk SQL thinking the databases are corrupt. If they are marked as corrupt then you need to restore from a normal SQL backup, so this aspect is critical to your recovery strategy.
The overall concept of using SAN-based replication for DR is fine. If you look at the Microsoft documentation about Windows 2008 stretch clustering with SQL 2008 you will find that block-level replication (e.g. SAN replication) is a mandatory part of this.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply