SMVI 2.0 and snapvault

We are planning to utilize snapvault to retain older smvi snapshots offsite.  The "recent" naming convention of the most recent snapshot was what we were looking for so we didn't have to script our snapvults.  However on initial testing, it appears that the secondary filer still looks for a recent.0 snapshot.  With out the ".0", the scheduled snapshots fail.  We will be able to script much easier now that there is a consistent name to look for, but i was hoping that this wouldn't be necessary.  Any hope that instead of SMVI naming the most recent snapshot "smvi_jobname_recent", naming it "smvi_jobname_recent.0"

Re: SMVI 2.0 and snapvault

Dear All,

After many months of waiting for SMVI2.0 to come out on the IBM site, we still need to script to get the snapvaults updated. Is there not a way to create recent.0 snapshots as jdmarinonbc describes.

This really is stupid, now i still need a script because the snaps are not named recent.0. This is the only thing i want in live.... no scripting for the snapvaults .

Anybody with an solution?

Re: SMVI 2.0 and snapvault


We have a sample script for SnapVault in the best practices guide (Appendix E)

Will this help?



Re: SMVI 2.0 and snapvault

Dear Amritad,

Thanx for the guide, we allready have scripts for the snapvaults, but that is just the problem we don't want to use scripts. The only thing we need is a "recent.0" snapshot instead of a "recent" snapshot.

The snapvault snap sched -x command uses the numbering schedule, it only looks for recent.0 snapshots.

Is there anybody with an solution??

Re: SMVI 2.0 and snapvault

I'm afraid at this point you still need a script to control the transfer, (we fixed the .0 issue and the next version of SMVI will eliminate this) Here are some instructions on setting up the script (which is short and simple) and a secure userid to make the api call.

First you will want to create a user on the NetApp controller with very limited permissions. From the NetApp command line;

Useradmin role add limited-sv-role –a api-snapvault-secondary-initiate-incremental-transfer,snapvault-secondary-initiate-snapshot-create, login-http-admin

Next create a user group which uses the above role;

Useradmin group add limited-sv-group –r limited-sv-role

Now create the actual user;

Useradmin user add limited-smvi-user –g limited-sv-group

Finally set the users password

Passwd limited-sv-user password

Now you have a user who can only call the SnapVault update API, very secure. Next we install the NetApp SDK onto the SMVI server. Then build your update script and save it in the C:\Program Files\NetApp\SMVI\server\scripts directory. Mine looked like this;

goto ende

chdir "c:\Program Files\NetApp\ontapi"
apitest.exe torfiler3 limited-sv-user smv1rocks snapvault-secondary-initiate-incremental-transfer primary-snapshot smvi_weeklyBlock1_recent secondary-path /vol/vmblock1vault/vmblock1
goto ende

chdir "c:\Program Files\NetApp\ontapi"
apitest.exe torfiler3 limited-sv-user smv1rocks snapvault-secondary-initiate-snapshot-create schedule-name smvi_weeklyvault volume-name vmblock1vault
goto ende


EXIT /b 0

Where the script above first creates a new snapshot on the vault and rotates the snapshot names as needed, then in the post backup phase makes the API call into the NetApp controller and initiates the SnapVault update specifying the most recent backup name SMVI 2.0 creates.