2009-10-21 06:37 PM - last edited on 2014-09-26 07:39 AM by allison
I have been told by a few SEs at NetApp that I have to use SMSQL to get an application consistent snapshot for SQL. The problem is, I am running SQL Server 2005 in a VM. I thought the SnapManager line of products were primary for taking application-consistent snapshots on physical machines OR for VMs with RDMs setup in physical compatibility mode. Will SMSQL work in VMs in virtual compatibility mode?
I have also tried using SMVI 1.2R1. Now, I know this is not as flexible as the SM products, but it can work with the right combination of products so I have been told. In other words, SMVI with VMware Tools VSS driver enabled plus the SQL VSS writer enabled, should produce an application-consistent snapshot. However, for some reason, this doesn't work with Windows 2008 Server, but seems to work with Windows 2003 Server. Can anyone verify this? The main limitation with this scheme is that it is a specific point in time snapshot, it doesn't truncate the logs and you can't roll logs forwards. For most of my customers, this is OK, except possibly truncating the logs.
I am just trying to figure out the best combination of products to use to get an application consistent snapshot for SQL Server 2005/2008. Any suggestions???
Thanks for the help in advance!!!
2009-10-21 08:39 PM
SMSQL/SnapDrive is definitely supported in a VM. The RDMs have to be in physical compatibility mode. Currently SMSQL/SnapDrive is supported for guest connected LUNs using MS iSCSI S/W initiator, and FC RDMs. Support for iSCSI RDMs will be available in Dec 09.
The "SMVI only" solution for application consistent backup of SQL Server databases leverages VSS Requestor in VMware Tools which is called as part of the VMware snapshot invoked by SMVI. As you mentioned, it does not truncate t-logs. Therefore, this is good solution for databases where t-level recovery is not important. For those databases, you can change the recovery model to "Simple" to ensure automatic t-log truncation. This solution ensures point in time recovery only. You are right, this does not work on Windows Server 2008 currently. You should check with VMware on when they intend to add support for Windows Server 2008.
Please check TR-3785 that highlights both the solutions for different scenarios.
Therefore based on the database and OS requirements, you could decide on the solution mix.
Hope this helps.