Having taken the plunge and giving 4.0c a test drive so far it looks very promising to better support SMSQL and registering the snapshots in PM. I am running into a bit of a pickle though.
I have 3 volumes for my SMSQL protected database: data, log, snapinfo. I have PM already setup for VSM -> SV. The luns for data and log are in a qtrees, while snapinfo is not.
In my PM dataset, the physical resources are a mix of qtrees and volume.
I do this because if I add just the volume for data and log, even though they contain no luns, PM builds a SV relationship for non-qtree data when setting up the 3rd leg. (ie: filer2:/vol/data/- -> filer3:/vol/data/<some_horrible_auto_generated_name>). I found that if I only assign the qtree then this unnecessary relationship is not built.
Now using SC 4.0c it seems to have better support for SMSQL and finds all 3 snapshots when trying to register w/ PM
It doesn't seem to like missing the non-qtree physical resource though.
########## Running NetApp Protection Manager Backup Version Create for dataset SMSQL_dataset ##########
[2013-02-15 18:06:46,628] INFO: STORAGE-05004: Creating Protection Manager driven backup of dataset [SMSQL_dataset] on storage controller [filer1].
[2013-02-15 18:06:46,628] ERROR: com.netapp.snapcreator.storage.executor.ZapiExecutorException: netapp.manage.NaAPIFailedException: Primary filer2:/log/- was not found in the dataset. (errno=13001)
Any suggestions on how to get this working with the qtree only?
########## Running NetApp Protection Manager Backup Version Create for dataset SQL_data ##########
[2013-02-17 12:53:29,785] INFO: STORAGE-05004: Creating Protection Manager driven backup of dataset [SQL_data] on storage controller [filer1].
[2013-02-17 12:53:29,785] ERROR: com.netapp.snapcreator.storage.executor.ZapiExecutorException: netapp.manage.NaAPIFailedException: Primary filer2:/coprodsqlsvr_log/- was not found in the dataset. (errno=13001)
Caused by: netapp.manage.NaAPIFailedException: Primary filer2:/coprodsqlsvr_log/- was not found in the dataset. (errno=13001)
... 11 more
Seems it's checking what is in the SnapMirror destination, the assigned physical resources on filer2 are all volumes:
Also, I should note that I could register backups like this in 3.6 with an additional config that would only register the backups, executed via a post-action from the main smsql config.
So it seems I had some issues with my log volume. There was an additional snapmirror relationship that was in unknown status present for the log volume. The best I can tell is that at some point in the past I deleted the destination volume from the PM dataset and let PM re-baseline to a new destination volume.
Breaking this old relationship (and removing it from snapmirror.conf) was not enough, I eventually deleted the PM dataset, recreated it, imported the external relationships for data, snapinfo, and then snapmirror init the log volume to a new destination volume. After the snapmirror init was complete, I imported the external relationship into the PM dataset and tried the backup though SC again. After all that, everything works as expected.
I ended up running into this again on a SMSQL data volume that is doing just SV. Seems that there is some issue with 4.0c and how it is checking the remote (SM or SV) copies. This configuration worked with 3.6.
In case anyone else runs into this issue. It appears to only trigger when using any type of SV in the PM dataset. SC 4.0.0c was incorrectly parsing information from PM and then creating an erroneous call to PM when registering the backup. This issue was reported on github, as issue #1241, commit to fix is also 4.0.0x branch.