I've been using NetApp SnapManager for SQL for almost 2 years now. Like all snapshot technologies, it is quick, handy and useful when it works, but should not become your only solution for backups and restores. We have experienced around a 10% failure rate on our largest databases. (3-5 TB) The configuration tool is woefully inadequate and counterintuitive, and must be run anytime there's a change in drive structure or database structure (adding more .ndf files, etc) Not sure why NetApp hasn't simply built in an automated system to query the master and msdb databases for this info. I would say the interface itself shouldn't be used to manage more than 10 servers at once, so I have broken our servers into different divisions as well as functional groups. (Dev, Test, Prod) and manage each group from a different control server. This works well. Attempting to manage all 100+ servers from one interface would be madness.

We use clones a lot for testing and validation, they are very handy but be cautious with them. They contain actual live data, and must be secured accordingly. The PowerShell cmdlets that allow for automation of cloning do not include options for selecting several vital pieces of information, such as the connector, used to mount the drives. Instead, they default to the first connector in a list stored somewhere in NetApps. If a server ends up with clone drives attached that use a Fiber Channel connector, rather than an iSCSI connector, the server will die if it's controller dies, rather than vMotion to another controller. This negates the DR/BC functionality that makes NetApp so peachy-keen. This is because FC is host-dependant, whereas iSCSI can be "grouped" in igroups managed by multiple host machines. Hence we manually mount clones (until this is fixed by NetApp) directly from consistent snapshots taken by SnapManager. Quiescing the SQL databases and thus taking consistent snapshots is one of the most useful features of SnapManager. This process takes microseconds to finish, but seems to fail in about 10% of cases ... hence my warning above. This SHOULD NOT be your only strategy!

If it sounds as though you will need to become a storage administrator to make things work, you will at the very least need to understand many of the details of SAN/NAS management using NetApps. We maintain 5 different backup/restore strategies, with SnapManager being just one of them. Another of our strategies involves using NetApps to mirror to a another remote NetApps installation. We also do periodic classic backups, and frequent T-Log backups, which are immediately mirrored to a remote location. We also mirror differentials of all our critical DB servers to a remote location, as well as fall back, when needed, on classic tape drive backups stored offsite at yet another secure location.

As DBA's we should all know that nothing is ever easy or flawless, so it's common sense not to put all your eggs in one basket.

Cheers!

-Rick