Our primary storage is NetApp, so we rely on the built-in snapshot capability quite a bit for our data protection. We evaluated VSC and I looked into Veeam as a method of restoring from those snapshots, but we didn’t really have the amount of restore requests to warrant opening up that kind of access to the NetApp. Our workaround process was a homegrown Powershell script that will do a SIS-Clone of a VM files and folder from a specific snapshot and place those files into a subfolder on the same Datastore.
This process works fairly well, the restore is quick and space efficient and you don’t have to deal with extra FLEX clones and NFS mounts on your host. You could unregister the old VM and register the new VM fairly quickly. The one ‘issue’ is that the VM files are in a subfolder called ‘restore’ in the Datastore, not the best place to run a VM from permanently. You could move the folder using the datastore browser, but that seems to be hit or miss in terms of whether it’s a full copy or move, Brian Graf’s blog says that individual file moves in 5.5 thick client are a full copy. My experience has been mixed with folders, I have seen a full move, a copy, and a folder disappear after a move. This is fixed in the 6.0 Web Client, but our entire environment is still 5.5.
A solution, that I tried last night, is fairly simple:
- Register the recovered VM in it’s ‘subfolder’
- Storage vMotion the VM to another datastore (in my case I went to one that doesn’t use snapshots)
- In original recovery location, there will be an empty folder with the name of the VM, delete that folder
- Storage vMotion the VM back to the original datastore
Fairly straightforward, just don’t forget step 3 (deleting the leftover folder). If you storage vMotion back to the original location without deleting that folder, the contents of the VM will go to that leftover folder (that is in the subfolder) vs being a the root of the datastore.