Backing up an MS SQL cluster

[danm]

We have an MS-SQL cluster with 2 VM nodes, system drives in a datastore, shared Data and Quorum disks mapped via virtual RDM and connected via SCSI bus sharing.

We need to back it up, and were hoping to use Veeam, however that fact that we are using SCSI bus sharing prevents us from doing this.

Does anyone have any recommended strategies for backing up a MS cluster in Veeam?

cheers

DanM

[Gostev]

Hi Dan, this is not possible with either Veeam nor any other VMware backup product, because VMware does not support snapshotting VM with disks engaged in SCSI bus sharing. While the snapshot is a requirement for image-level backup of VMware.

[cwells]

I apologize if this has been discussed before (I searched but couldn’t find any related topics).

We have a 2 node SQL 2008 R2 cluster. I set it up with Microsoft (in-guest) iscsi for the shared storage, only to realize later that Veeam cannot backup the shared storage where my SQL databases reside.

So I have started researching using VMWare RDM’s for the shared storage so that I can use Veeam to backup my databases. My understanding for Veeam to backup a RDM it needs to be a virtual instance, however according to the VMWare knowledge base (link below) in order to share a RDM between two VM’s the RDM needs to be physical.

Am I missing something here? Or can Veeam not backup a SQL cluster with shared storage?

Also, what type of iscsi storage setup are most of you out there using for SQL clusters? I believe I got a free license for starwind iscsi through Veeam but I’d rather stick with Microsoft or VMware.


http://kb.vmware.com/selfservice/micros ... Id=1029699

[dellock6]

Another option is to completely avoid RDM devices and go with VMDK, using the multi-writer mode:

http://kb.vmware.com/selfservice/micros ... Id=1034165

This is for example the only supported mode for running Oracle RAC, but it also applies to other guest cluster.

Luca.

[cwells]

thanks for the reply. I am not familiar the writer flag option so thanks for the hot tip.


One concern i have from that article is:

"Linked clones and snapshots are not supported. Be aware that other vSphere activities utilize cloning and that backup solutions leverage snapshotting via the vAPIs."

If i'm reading that correctly, how can Veeam backup the shared storage if snapshots aren't supported?

[dellock6]

For what I recall, in that case snapshots are not supported, meaning you can do them but VMware will not have any responsibilities if something go wrong. We have used that feature in the past for Oracle, but we set shared disk in indipendent mode and made backup via internal guest procedures.
It's something we should try...

Luca.

[DChiavari]

I just tried this in my lab, to test whether it's possible to take snapshots of a VM with one or more VMDKs set to "multi-writer" sharing.

I used a test Win2003 x64 VM I had, attached a 2GB VMDK to it while powered off (new SCSI controller, disk 1:0), set "multi-writer" sharing. Then I started the VM, logged on and initialized disk, formatted it and put some files into it. After that I tried to take a snapshot.

It turns out it is technically possible... but as soon as it completes, the VM gets a hard stop and powers off. Pretty nasty.

vmware.log shows:

Code: Select all

vmx| [msg.disklib.sharedDiskConf] Cannot open snaphot disk '/vmfs/volumes/4f38ee75-af3422f3-f117-000c297484fd/Fornax/Fornax_1-000001.vmdk' as a shared disk.

(omissis...)

vmx| Msg_Post: Error
vmx| [msg.checkpoint.continuesync.fail] An error occurred while restarting virtual machine after taking a snapshot. The virtual machine will be powered off.

Also, you cannot power on the VM unless you delete (commit) all snapshots, since the hypervisor won't be able to open the disk.

So it seems the problem is that the delta disk cannot be shared. I've only tried this on an ESXi host v4.1 u2, don't know about v5.x (but I suspect it will have the same behaviour).

[tdewin]

Danilo,

Interesting, did you also try by putting the disk on independent like Luca has proposed? In this case I'm not seeing any problems with creating the snapshot / committing it because the disk is not being snapshotted (but i just ran a simple test)