Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Moving to a new data center. The data center is going to use SRM replication for vm's, and netapp snap manager for sql for sql backups. We are currently using full/tlog native backups. How do the new standards compare to the current standards and can I safely stop the native backups?

share|improve this question
In my experience, Snap manager is much more faster than native backups. Anyway, what is important about backup, is restoring, and the restore can be more difficult with this system. I will recomend you that test the software to the max, and if you're pleased, then move with confidence. – Carlos Garcia Feb 9 '11 at 16:01
up vote 4 down vote accepted

NetApp SnapManager pros:

  • Full backups take a second or less no matter how big the database is.
  • Full backups don't slow the SQL Server down because no data is dragged over the SAN connection.
  • Tape backup drives can be hooked directly up to the SAN, enabling screaming fast backups of the snapshot.
  • You can mount the snapshots on your dev or QA servers for testing with minimal slowdowns to production (if they're configured right)

NetApp SnapManager cons:

  • The snapshots are still on the SAN. If your SAN controller dies, you're screwed, and SAN controllers do die.
  • If you need to frequently refresh a dev/QA SQL Server from production data and that server isn't using the same NetApp SAN, you still have to shuffle data over to that other SAN. You can do it, but it's just a little more intricate than using conventional log shipping.

Native pros:

  • It's fully under the DBA's control. He doesn't wonder whether the SAN is running out of space for snapshots. (You can mitigate this by getting involved with your SAN administrator, and I don't mean romantically involved, although I suppose that would work too.)
  • If you need to log ship to multiple servers for reporting purposes, and those other servers aren't on NetApp SANs (like they're using local storage or Fusion-IO), then log shipping is easier to manage.
  • Free and integrated with SQL Server.

Native cons:

  • Much, much, much slower full backups that impact production queries.
share|improve this answer

We use netapp's snap manager for SQL. It is a fast backup, but I have issues every now and again. Somtimes I will encounter busy lun snapshots. Once it get a busy lun it starts creating more and more busy lun snapshots and will eventually fill up the snapshot space causing all the backups to fail. The only way to get rid of them is to detroy the busy luns and then delete the snapshots of those luns and everything will start backing up correctly again. I have not had any luck stopping the busy luns from being created. Of course, I have not contacted the vendor yet, I am just dealing with the issue when it happens.

share|improve this answer

It's been a while since I worked with them, but I found the Netapp Snap Manager for SQL tool to be lacking when it counted; during a restore. You have no visibility or recourse into how the restore goes and it often failed. If I had a chance, I'd not use Netapp snaps for backup again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.