I've been using SnapManager for the last year after inheriting it with the job. It works great ... when it works. SnapDrive is a moderately unstable dependancy of SnapManager, and we seem to lose a SnapDrive installation at least weekly across 120 or so servers. A repair installation is then required, and it all comes back just peachy-keen. Also, SnapDrive has a 2 TB limitation on the backing volume for any LUN. This limitation thankfully went away with SnapDrive 6.5, however came back once we upgraded vSphere to version 5.1. Some form of interoperability issue. It has killed our ability to use NetApp Snap products to clone or restore our most critical databases. The folks at vSphere indicate this is fixed in vCenter 5.5, but it's an upgrade we're likely to be studying for another month or more, wondering what else will bite us.

We use SnapManager as part of a 5 tier backup/recovery system. When it works, it's fast and efficient and usually the first method of recovery we attempt. However we cover our other bases as well, by also taking traditional full backups + differentials and frequent t-log backups. We also use NetApps to mirror our data drives and t-log backups to a remote data center, as well as snapshotting our RDM volumes datastores frequently and snapshotting our vmdks datastores in vSphere frequently. Finally, we push the traditional backups to tape nightly, and ship them to the bank. We have discovered corrupted snapshots when testing our SnapManager backups, and had to fail to other recovery tiers before. Frankly, I would not put all my eggs in any single basket, as each of the methods I've detailed above have failed at one time or another. I suppose my point is, SnapManger is not a replacement for traditional backups or DR methods, but can be used to augment them, providing a fast and efficient path to recovery ... when it works.