Question about RDM, MSCS, and storage snapshots

[bmekler]

We're planning to deploy Veeam Backup with a new vSphere 5.5 cluster using NetApp (cDOT 8.2.2) for shared storage. As I understand, Veeam v8 Enterprise is bringing support for backing up NetApp filers using WAFL-based snapshots instead of VMware virtual machine snapshots. Part of our deployment is a two-node MSCS virtual cluster running SQL Server. Typically, when setting up such clusters, we use in-guest iSCSI initiators to access shared LUNs, then set up either application-level backup or SnapMirror to another filer to back up the databases. In this case, the budget does not allow for a SnapMirror target, but I'm wondering - will it be possible to use virtual-mode RDMs in place of in-guest iSCSI initiators, and then use Veeam with storage-based snapshots to back up the entire cluster including database LUNs? I know that normally the answer would be "no, not for a cluster", as MSCS is not compatible with virtual machine snapshots which are required for Veeam to function, but in this case virtual machine snapshots would not be involved, would they?

[foggy]

Boris, while generally vRDM is fine, VMware snapshot is still triggered as a part of the backup from SAN snapshot process, so I don't think Veeam B&R can be used in this case.

[bmekler]

I see. That's too bad, it could've been a nice feature. Thank you for the clarification.

[foggy]

But that would leave backups crash-consistent. Actually, if you're ok with crash-consistent backups, you could schedule regular SAN snapshots on your storage and use Veeam Explorer for SAN Snapshots for restores.

Thanks for the feedback, anyway.

[Vitaliy S.]

In addition to this, if you cannot do application-aware VM snapshots, then I would suggest using MS SQL Studio to backup database logs and then use crash-consistent LUN snapshots for recovery purposes.

[bmekler]

Application-aware SAN snapshots are not a problem - NetApp's SnapManager for SQL Server tells the SQL instance (standalone or clustered) to freeze the IO on a set of databases (by default, up to 35 at a time), then tells the array via SnapDrive and ZAPI to snapshot the volume, and then tells SQL again to unfreeze the IO - this results in an application-consistent database snapshot. The problem is getting that snapshot to secondary/tertiary storage without a second NetApp array to do SnapMirror/SnapVault. Is it possible to script Veeam to access and back up existing SAN snapshots (i.e. the ones generated by SnapManager rather than Veeam itself)?

[bmekler]

Actually, now that I think about it, with cDOT and SQL 2014, it will be even easier than that - I'll be able to deploy the databases on an SMB 3.0 share, then simply robocopy application-consistent .mdf and .ldf files from the \~snapshot\recent folder(s), then have Windows Server 2012 R2 deduplicate them - no need for Veeam backups.

[Vitaliy S.]

Hi Boris,

Yes, Robocopy seems like a way out, however you can also consider dumping SQL backups on any supported virtual disk (VM) and then backing it up with Veeam. This will allow you to use retention policies within Veeam and store these files in compressed and deduped format.

Thanks!

[bmekler]

Another question, sorry to be a bother - I know that with Windows Server 2008 R2, MSCS, and a clustered SQL Server 2008 R2 instance using shared LUNs attached via in-guest iSCSI initiator, backing up the OS VMDK using any tool that takes a VM snapshot is a problem, because cluster service panics when it detects the brief pause caused by snapshot creation/consolidation. Right now, I use Windows Server's built-in backup in order to work around that. Is this still the case with Windows Server 2012 R2 and SQL Server 2014 using SMB 3.0 shares for all databases (system, temp and user), or does it tolerate VM snapshots now?

[Vitaliy S.]

Not sure I have an answer to that, but you can search community forums for the feedback from customers that are using this setup already. On as side note, I thought that there is some tolerance timeout for SQL Server clusters that can be fine tuned to address snapshot creation/commit operations (but I might be wrong).

[bmekler]

I can't find a straight answer; guess I'll have to test it once the hardware lands here. My guess would be a no though, as VMware's support document makes no distinction between SQL clustering using any type of shared storage (in-guest iSCSI, pRDM, vRDM, SMB) and expressly says that VMotion and SVMotion are not supported, so I guess snapshots are out too. It's too bad that Veeam does not support doing crash-consistent backups from storage snapshots without doing a VM snapshot; these would be useful for DR purposes.