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?
Please try updating your PM dataset as below.
Non-qtree data is represented as '-' in DFM. When a LUN is created under a volume it becomes a non-qtree data (does not belong to any qtree).
Please let us know if this resolves.
Snapcreator Community Moderator
I changed the PM dataset so that it only includes the following 3 qtrees:
I am still getting the error from SC when it goes to register the backup in PM:
[2013-02-17 12:53:28,724] INFO: STORAGE-03045: Protection Manager dataset modify successful for dataset [SQL_data]
########## 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.
Qtree Snapmirror /vol/snapinfo/- will provide you with qsm (it only grabs data NOT in a qtree)
If you have qtrees also part of the above volume you will have to add seperate qtree entries as well.
If it is only snapvault,
/vol/snapinfo/ (NO DASH after the trailing /)
Please let me know if it works.
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.
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.