SnapProtect Question [ Edited ]

[#1]

Hello,

I have a problem restoring backed up databases with snapprotect.

Our setup is:

We have a FAS6250 Metrocluster with on each node a NFS datastore for our VM disks. Our SQL Server servers have their own rdm luns for database and logfile luns in a volume per server instance. We use FCoE connectivity.

Backup works fine, not every day 100% but most of the time the backups complete succesfully.

When I try to restore a database to the original server we run into a problem. The error message is:

Error Code: [32:392]
Description: The client machine initiator address is not visible on the file server. Please check the SAN or iSCSI connectivity between the file server and the client. : [Initiators on host:[**********] Are not logged into file server:[***********]. Please check the SAN or iSCSI connectivity between the file server and the client.]
Source:***********, Process: CVD

I cannot understand why snapprotect cannot let the server connect to the storage system, when I use snapdrive on that server it shows me all the disks, so the SAN connectivity is ok.

Additional info: we use one disk as a mountdisk, the luns are connected via mountpoints on this disk, again, each sql instance has its own mountdir with a mountdir per lun.

I can connect to a lun in a snapshot using snapdrive on the server. So that would be a workaround for not being able to restore with SnapProtect, but I'd rather restore using SnapProtect so I can delegate restore requests to other people :-)

Hope anyone can help me with this.

[#2]

I'm pretty sure that RDM are not supported by CommVault Simpana / SnapProtect when using snapshots (Intellisnap). You have to use either NFS or iSCSI from within the VM.

[#3]

That's a shame, I hoped that non iSCSI vm connectivity would be supported by now. We are able to use physical RDM's but our design is non iSCSI, looks like we still have to implement iSCSI or use the workaround by manualy connecting snapshot luns and copying the files with windows explorer.

Is non-iSCSI vm RDM support on the roadmap for SnapProtect?

[#4]

This might help:

SQL in a VM best practices. I'm struggling to understand how the SQL bit works, not being much of an SQL guy. Anyway would you present RDMs (either vmware pRDMs or via vm guest iscsi maybe?) and treat it as a physical host, or do you leave it inside the vmdk and some sort of other magic happens to backup the DB?   <<<  If you want to use the SQL agent to perform backup and recovery of the databases then you would put the database in an RDM (iSCSI) and treat it as a physical host.    In a VMDK you can't use the SQL agent.  You would protect the VM (Virtual Server Agent) and use the "Application aware backup for granular recovery" option in the subclient.  However, your recovery in this case would basically be to recover the VM (just that the database was quiesced

http://community.netapp.com/t5/Data-ONTAP-Discussions/SnapProtect-questions/td-p/15497/page/11

It sounds like you do need to configure the iSCSI initiator on the filer to allow the restore. Maybe test it by configuring an initiator group but don't map any LUN's and enabling the initiator on the guest and make a connection to the filer.

Also if it is a VM you may be able to use the VSA as mentioned.  

[#5]

I don't think we will ever see support for RDM volumes in a backup tool for VMware All backup applications for VMware rely on the VMware snapshot which isn't possbile to do on RDM volumes.

When using inhost iSCSI you installe the SQL agent. That can backup the db and log files using NetApp snapshots.

SnapManager for SQL allow you to snap VMware RDM volumes becourse SnapDrive can handle it. SnapProtect / CommVault doesn't use SnapDrive and can't handle it.