July 8, 2009 at 9:07 am
Hello,
Is anyone using Netapp's Snapmanager for SQL to do backups/restores? Have you had any issues with it? All comments are appreciated.
Thanks.
July 8, 2010 at 11:18 am
Craig,
We have started adopting NETApp Snap Manager for SQL Server, and it looks like the road will be long and steep.
I have not found any recommendations for NETApp as far as standardizing on an enterprise level, so each server we tackle is being done one at a time, as far as configuring backups.
Couple that with the fact that we were not involved up-front (a perennial SQL DBA complaint), so we have to backfit several hundred servers to work with NETApp.
Have you had any luck?
Thanks,
Jeff
July 8, 2010 at 11:26 am
We have not purchased the software at this time. One of the reasons is that I fail to see the business value in it and was able to convince management of this , at least for now. Also, we are using Snapmanager for Exchange and had extreme problems getting it to work and configured. Can you share some of the details of your experience? Sounds like it is very labor intensive.
Thanks, Craig
July 9, 2010 at 8:57 am
Craig,
NETApp is very good for what it was designed to do, which is, taking very fast snapshot backups of entire drives. This is an awesome tool from a storage tech's point of view. Not so much for DBA's. Where we are in our adoption of this tool is that we have no choice but to convert from backups on local drives or SAN drives (Tivoli) to using this volume backup methodology.
NetApp recommends that system database files remain local to the SQL Server physical server, while all other database files are split out on LUNS that are on the NetApp appliance. So my mdf files reside on one LUN, and my ldf's on another, with additional LUNS available for tempdb, and finally backups. And SM only likes 35 dbs on a LUN. So if I have 75 DBs on my server, I should have at least 8 luns with database files going to several locations. Think of the documentation to maintain and having to find the needed files during an emergency.
Moving to the new LUNS requires coordination between the storage folks, the server folks, the DBA team, and the user-base to move the files to their new homes. That is a lot of work.
One of the most highly touted benefits of SM is Fast backup and restore. You should know that this is only true if you plan on restoring ALL of your databases that are assigned to the LUNs that contain the data. Otherwise, your restore time and complexity INCREASE because the entire contents of the backed-up drive must be mounted, and then searched for the relevant database bits to restore. Problems we have encountered include
1) not having enough space to mount the drive allocated;
2) increased recovery time for a single database when many are assigned to a set of LUNs;
3) occasional SnapManager hiccups that make backups stop working;
4) The software backups manage the Log Sequence Numbers (LSNs) so if you take a native backup, you will have to recreate the backups using the SM tool, which is ok but not great. It will create a job to perform the backups, but we were kind of wanting a way to script this for standardization, and that still eludes us.
5) requirement for multiple backup strategies because system db backups are not part of what SM does. So now you have to have a backup plan for system db's, and one for user db's, if you didn't split those out before.
6) Determining the mix of databases to place on the same LUNs can be very problematic to triage. Business critical dbs should be on their own LUNS, and so should highly transactional dbs, but do you want to become a SAN specialist ? You will if you have to carve out LUNS for each special db on a server with 100 dbs.
Hope this helps.
Jeff
July 9, 2010 at 9:15 am
Thanks for the insight, Jeff. That further reinforces my preference for the native tools. I can deploy my backup/maintenance jobs in about 2 minutes. Hope all works out ok for you.
July 10, 2010 at 12:03 pm
Hi All,
I am interested to know if anyone has tested IBM Tivoli Storage FlashCopy Manager for SQL in production. I have read a good tutorial about it at: IBM Tivoli Storage Flash Copy Manager which make it seems quite good of a product, but I really would like to hear from some one who tried it in production.
Thanks in advance,
MSright1981
August 4, 2010 at 3:23 am
How long did you find it takes to restore a snap of a LUN? Also, how large do the snaps grow to once taken? I know this is very much "it depends" but just looking at a rough estimate, whether they grow to 10GB or 100GB daily once snapped. Is it a like for like, as in if you increased the size of a standard DB by 10Gb would a snap grow by 10GB as well?
_________________________________________________________________________________SQLGeordieWeb:- Jarrin ConsultancyBlog:- www.chrisjarrintaylor.co.ukTwitter:- @SQLGeordie
July 12, 2011 at 7:44 am
I've written a few articles at MSSQLTips concerning implementing SMSQL and also testing backup times with snaps and streaming backups. http://www.mssqltips.com/author.asp?authorid=55.
We implemented SMSQL on a grand scale starting about 8 months ago. We currently have about 50 SQL Servers running the software. I can now safely say we've essentially hit the limits of what SMSQL is capable of managing. The interface is just not made to manage a large number of servers and the random problems the NetApp snap technology has with virtual machines is too much to handle. I will be finishing a blog post this afternoon outlining everything we've learned. Feel free to check it out at http://www.blogofshaw.blogspot.com.
Also, I'll be working directly with NetApp over the next month or so providing them suggestions and real-world examples of the problems we have with the tool and how they can improve it. I have to say NetApp has been very receptive and have been honest and aware of the tool's limitations. As of now though, we are moving a majority of our systems off of SMSQL and back to Idera's SQLSafe.
July 12, 2011 at 8:13 am
scott.shaw (7/12/2011)
I've written a few articles at MSSQLTips concerning implementing SMSQL and also testing backup times with snaps and streaming backups. http://www.mssqltips.com/author.asp?authorid=55.We implemented SMSQL on a grand scale starting about 8 months ago. We currently have about 50 SQL Servers running the software. I can now safely say we've essentially hit the limits of what SMSQL is capable of managing. The interface is just not made to manage a large number of servers and the random problems the NetApp snap technology has with virtual machines is too much to handle. I will be finishing a blog post this afternoon outlining everything we've learned. Feel free to check it out at http://www.blogofshaw.blogspot.com.
Also, I'll be working directly with NetApp over the next month or so providing them suggestions and real-world examples of the problems we have with the tool and how they can improve it. I have to say NetApp has been very receptive and have been honest and aware of the tool's limitations. As of now though, we are moving a majority of our systems off of SMSQL and back to Idera's SQLSafe.
Scott - looking forward to the post. We are using SnapManager for SQL and it does work but does have some weaknesses and IMO some excessive maintenance overhead. Recovery can be very quick but you are also looking at different teams to be involved for recovery efforts unless you make your DBA's SAN admins as well. Our usage is only on a few servers so, the complexities that you speak of with 50 is not something that we are hitting presently. Again, looking forward to your post. Thanks for sharing.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
July 12, 2011 at 2:34 pm
I've posted my blog. I hope it helps. To summarize:
1. Management Console too slow when more than 20 servers are registered. Your mileage may vary
2. Random, reoccurring errrors add huge operational overhead and wastes man hours. Some of these issue are due to SnapDrive not working well in virtual environment. Even our storage folks are at their wits end.
3. Management Console configuration not tightly integrated with SQL Server. Systems which add or remove databases frequently should not use SMSQL
So, what systems are good for SMSQL?
1. Systems with 1 large database (>200GB)
2. Shops with only a few SQL Servers (<10)
3. Shops not running SQL Server on VM
4. Shops who do not care about using SMSQL on systems already built or who are willing to go through the pains of reconfiguring those systems to use SMSQL
5. Systems that do not change often; ie, add or remove user databases.
I still want to stress to everyone that engineers at NetApp have so far been willing to work with us on the product's weaknesses. Admitting your problems is the first step to recovery. My company plans to hold them to that.
July 12, 2011 at 2:51 pm
Yes, read the blog and appreciated the information. We have run into most of those issues as well. I did find some suggestions to eliminate the need for reconfiguration with every database add / remove but haven't tested that yet. I will soon and let you know what I find.
One question, are you using this for DR or strictly backup / recovery? Are you using FlexClones at all?
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
August 24, 2011 at 12:05 pm
I'm about ready to jump into SMSQL 5.1 on VM SQL and was wondering why you caution against VM based SQL with SMSQL?
Pete
Pistol Pete
August 24, 2011 at 3:27 pm
petedoyon (8/24/2011)
I'm about ready to jump into SMSQL 5.1 on VM SQL and was wondering why you caution against VM based SQL with SMSQL?Pete
I caution against using SMSQL for large environments (> 25 servers). We saw extreme manageability issues which NetApp did not deny. The technology is good but the means to manage it is not. I got word that NetApp is looking to Syncsort as a 3rd party solution. I haven't used the product but from demos it looks more geared to SAN admins than DBAs.
August 24, 2011 at 3:31 pm
David Benoit (7/12/2011)
Yes, read the blog and appreciated the information. We have run into most of those issues as well. I did find some suggestions to eliminate the need for reconfiguration with every database add / remove but haven't tested that yet. I will soon and let you know what I find.One question, are you using this for DR or strictly backup / recovery? Are you using FlexClones at all?
I'd be interested to know how the database add/remove testing goes. There is such a disconnect between the SMSQL console and SQL Server that we could never get it to work.
We were only using it for backup and recovery. We tried some cloning but it was spotty. Oddly enough my DBA team would be unable to complete the clone but my SAN admin could. Nice technology but very frustrating.
August 25, 2011 at 7:32 am
scott.shaw (8/24/2011)
Nice technology but very frustrating.
Agreed. Mainly in that the tools are not there yet, not even in the ability to script things and make them automated. Definitely doesn't work when you are trying to manage multiple servers as you stated.
I haven't tested the configuration I mentioned yet as it hasn't been a present pain point and we have a few other things in the fire presently but will update when I am able to get to it.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 15 posts - 1 through 15 (of 53 total)
You must be logged in to reply to this topic. Login to reply