In the previous posts, I explained how to configure and use Veeam Explorer for SAN Snapshots to create san-based snapshots of your VMs and make them available directly inside Veeam Backup & Replication (VBR).
Now it’s time for the last post: how to use them to do restore operations.
One of the beauties of this tool is the complete integration with the standard backups already available in previous version. If you look at the backup console, you can do the same kind of restores available for usual backups:
From VBR point of view, there is nothing different, and I would finish the post here 🙂
Nonetheless, is interesting to see what happens behind the scenes when you start for example an Instant VM recovery.
When we start the restore operation, we are first asked for the desired restore point to start from. In VESS, it equals to one of the available snapshots:
Then, since an Instant VM Recovery powers up the restored VM directly in an ESXi host, the procedure asks for specific vSphere informations:
When the Instant VM recovery is finally launched, there are multiple views we can have of what happens. First, the Veeam view:
From this log you can understand in details how the whole process works:
– Veeam searches for the required snapshot
– it creates a smart clone volume (basically, a clone of the snapshot that can be seen as a standalone LUN from the connecting iscsi initiator)
– it creates a new iscsi target name (iqn)
– it launches a rescan on the target ESXi so it can see and mount the new LUN (remember it’s a clone of the original VMFS datastore, so it’s already formatted with a file system ESXi can use, it only needs to be resigned)
– it registers the VM inside the new LUN so it can be powered on from ESXi
You can see other details from the LeftHand Console:
Here you can see (I highlighted them) the original snapshot (lower left), the smartclone volume (upper left) and its new iqn number (right). The LUN has the same configuration parameters of its father: 120 Gb, my three ESXi hosts in the access list, but it’s only 1 Gb in size, that is the size of the snapshot. This is a great feature of LeftHand: the smartclone volume has the size of its original snapshot, instead of the parent lun. So multiple clone operations can be executed without consuming too much space on the storage.
Finally, we can see what happens inside vSphere:
The activities in the tasks pane are those described before. The final result is the vm named fileserver_restore listed in the VM list, and as you can see its vmdk is hosted inside the datastore named snap-2a378c60-vsa-snap-01, that is the smartclone volume.
How cool is it!
When you finished restoring your VM (and the same procedure applies for file level restore or exchange server objects…) you can simply stop publishing the Instant VM, and all the activities described before are reverted to bring your environment to its previous state:
In the meantime, the scheduled snapshot on the LeftHand storage is going on based on your schedule, so no new data is lost in case you are only restoring some files.
This post concludes the Veeam VESS series, hope you liked these posts, and you now have understood how to use this new awesome feature.