Keep in mind that these two scenarios meet different goals, and you get different restore capabilities depending on what design you implement.
SQL/Exch with data in guest connected iSCSI LUNs or FCP RDMs and Snapdrive and SMSQL/E inside the guest: In this case you use the SMSQL/E appliction inside the guest to get application consistency for data disks. You get full restore capabilities including point in time restores and the ablilty to roll logs foward (if you still have them of course) to recover to specific points in time that you select or as far forward as you can go. You also get other such features provided by the SMSQL/E products like backup validation that is done each time a snapshot is created. If you put SnapManager for Virtual Infrastructure into this environment then you get the ability to create NetApp snapshots of the virtual machine system disks. If you should need to recover the whole VM you would perform a VM recovery with SMVI, then go into the VM and use SMSQL/E to recover the database to the desired consistency point.
SQL/Exch with all data in vmdk disks, no Snapdrive or SMSQL/E in the guest, using SMVI: In this case you can enable VSS by using the VMware tools that ships with ESX 3.5U2 or later, and also enabling the application's VSS writer, in the case of SQL for example this is the SQL Writer. The goal of doing this, in an SMVI environment, is to ensure that the image of the whole VM that is captured in the NetApp snapshot is application consistent. Keep in mind that what SMVI does is capture a VMware VM snapshot inside of a NetApp snapshot. So enabling VSS in this manor is actually capturing application point-in-time consistency in the VMware snapshot, and then NetApp captures that. This is the same technique use by VMware's VCB 1.5 product to get application consistent backups. The VCB product create a VSS application consistent VMware snapshot of the whole VM, then mounts that snapshot and reads the data from it, in our case we do the same but instead of mounting and reading, we create a NetApp snapshot. This design is not intended to truncate log files for the purpose of providing restore capabilities such as individually restoring data disks vs. log disks then picking a restore point or rolling logs forward. This design is simply intended to ensure that the image of the VM being captured by SMVI is application consistent. Recovery of a VM with SMVI that has been backed up in this maner is more like a "restart" than a "restore". When performing the SMVI restore of the whole VM you are, in effect, restarting the VM back to a point-in-time, it just so happens that this point-in-time was made application consistent with the VSS writer. When the VM was made application consistent with the VSS call there were no truncation of logs or creating of restore points. However, when you perform a SMVI VM restore, as far as the Windows OS inside that VM is concerned, you are not performing a "restore" you are simply "restarting" the VM, which restarts the application, which comes up to the last point-in-time captured by VSS. This model does not provide any roll forward restore capability but it does capture a point-in-time application consistent whole VM image which can be restored all at once.
The SQL writer was shipped with SQL 2005 and installed but not enabled by default, in SQL 2005 SP2 it was enabled by default. In SQL 2008 it is installed by default. There is info about the SQL writers here, here, and here from MS tech net.
Larry Touchette
