Data Backup and Recovery

SMSQL and PM w/ 4.0c

clilescapario
5,799 Views

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.

filer1:/vol/data/data1/datalun1

filer1:/vol/log/log1/loglun1

filer1:/vol/snapinfo/snapinfolun

In my PM dataset, the physical resources are a mix of qtrees and volume.

filer1:/vol/data/data1

filer1:/vol/log/log1

filer1:/vol/snapinfo

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.

<pre>

########## 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)

</pre>

Any suggestions on how to get this working with the qtree only?

Thanks,

Chris

1 ACCEPTED SOLUTION

clilescapario
5,799 Views

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.

View solution in original post

9 REPLIES 9

sivar
5,799 Views

Hello Chris,

Please try updating your PM dataset as below.

filer1:/vol/data/data1

filer1:/vol/log/log1

filer1:/vol/snapinfo/-

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.

Thanks

Siva Ramanathan

Snapcreator Community Moderator

clilescapario
5,799 Views

Hi Siva,

I changed the PM dataset so that it only includes the following 3 qtrees:

filer1:/vol/data/data1

filer1:/vol/log/log1

filer1:/vol/snapinfo/-

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)

        at com.netapp.snapcreator.storage.executor.ZapiExecutorImpl.run(ZapiExecutorImpl.java:55)

        at com.netapp.snapcreator.storage.executor.DfmExecutor.run(DfmExecutor.java:65)

        at com.netapp.snapcreator.storage.api.dfm.DfmImpl.pmBackupCreate(DfmImpl.java:551)

        at com.netapp.snapcreator.storage.StorageCoreImpl.pmCreateBackup(StorageCoreImpl.java:598)

        at com.netapp.snapcreator.workflow.task.ProtectionManagerTask.execute(ProtectionManagerTask.java:132)

        at com.netapp.snapcreator.workflow.impl.SCTaskCallable.call(SCTaskCallable.java:48)

        at com.netapp.snapcreator.workflow.impl.SCTaskCallable.call(SCTaskCallable.java:20)

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

        at java.util.concurrent.FutureTask.run(FutureTask.java:166)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

        at java.lang.Thread.run(Thread.java:722)

Caused by: netapp.manage.NaAPIFailedException: Primary filer2:/coprodsqlsvr_log/- was not found in the dataset. (errno=13001)

        at netapp.manage.NaServer.invokeElem(NaServer.java:671)

        at com.netapp.snapcreator.storage.executor.ZapiExecutorImpl.run(ZapiExecutorImpl.java:46)

        ... 11 more

Seems it's checking what is in the SnapMirror destination, the assigned physical resources on filer2 are all volumes:

filer2:/vol/data_m

filer2:/vol/log_m

filer2:/vol/snapinfo_m

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.

Thanks!

--

Chris

sivar
5,799 Views

Hello Chris,

If you could, please email me the config files and dfpm relationship list details to sivar at netapp.com

I will check with my team and reply back.

Thanks,
Siva Ramanathan

sivar
5,799 Views

Chris,

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,

try

/vol/snapinfo/ (NO DASH after the trailing /)

Please let me know if it works.

clilescapario
5,799 Views

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.

clilescapario
5,799 Views

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.

sivar
5,799 Views

You are 100% correct. I am able to reproduce it every time in the lab as well.

I will keep you posted on the progress.

Please give me 3 more days on this.

clilescapario
5,800 Views

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.

sivar
5,799 Views

Thank you for all your efforts in finding a resolution and testing this.

I am recommending your name to receive a cool snapcreator t-shirt.

Public