SMVI 2.1.1 + SnapVault without scripts - Possible?

[ricardoduarte]

Hi there,

A year ago we were promised that the "next version" of SMVI 2.0 would fix the integration with SnapVault. The fix is simple: instead of naming the recent snap as "smvi_job_recent", just name it "smvi_job_recent.0".

From http://communities.netapp.com/message/23880#23880, "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)". This was on 18-Feb-2010.

So, now that two "next versions" are available, seems to me that this problem is still not fixed. I can only find the SV-SVMI script, and nothing about it not being required anymore.

Come on NetApp. How hard can it be to make SMVI name recent as "recent.0"?  Seems to me that it would only take a small string replacement in the code. VIBE works just fine with SnapVault, so why not your paid version?!

Regards,

[rmharwood]

I totally agree with this sentiment. Right now I am holding off switching from VIBE to SMVI because scripting is still required for Snapvault integration. I will be escalating this to our SE before long.

Richard

[keitha]

I can't comment on the reason for the delays or the difficulty it is the case that scripting is still required. I would encourage you however to take a look at SnapCreator. In the last year this tool has come leaps and bounds and is now the tool I recommend for customers wanting to SnapVault their VM environments. (the SV-SMVI tool works very well and the script does not have to be customized for each job and is only 3-5 lines long)

SnapCreator uses the Vibe engine and offers GUI setup and management of SnapVault. Very nice.

Keith

[JANDREWARTHA]

OnCommand Host/Core 5.0 can perform non-scripted SMVI backups that go to a snapvault.

[rmharwood]

Can you point to any documentation that describes how to do this? What about restores from snapvaulted backups?

[JANDREWARTHA]

The OnCommand Host documentation is the place to start, although it's a bit incomplete in that it doesn't tell you that your storage service should only have remote retention policies, not a transfer schedule (as the snapvault is done by OnCommand rather than the storage service by ticking the "back up to remote" option checkbox). Actually, I lie, it does if you know what to look for, but good look understanding the terminology it uses. I haven't tested a restore from a snapvaulted backup, but there's a big restore button in the Backups tab that I've tested as mounting local backups fine, and the doco (Guide to Common Workflows) says " You can mount a local backup and a remote backup on any ESX host that is managed by the same host service that was used when the backup was created. "

[MKOT_ITEXPERT]

There's a nice guide on the communities site. If you haven't seen it yet it's there:

https://communities.netapp.com/thread/19792

Restores are made from OnCommand console and both local and remote are visible.

Regards,

[JANDREWARTHA]

So further word from NetApp support is you can't do Single File Restore with OnCommand Host, and also there will be no further development so go back to using VSC.

[rmharwood]

No further development of OnCommand Host? Or no plans to include single file restore? I don't understand why NetApp have two slightly different products doing similar things, each with important missing pieces of functionality or usability.