Skip to main content

Hello,

To improve out RTO time we are thinking about following scenario:

current we backup VM via VSA backup to MA, and AuxCopy then the data to a CIFS share which is sitting on a NetApp with SnapLock configured . In case of ransomware attack, we will restoration via VM restoration process from the CIFS share.

In future we want restore in case of disaster direct the volume which host the VMs

now my question is possible to handle this during commvault completely?  VM backup configured with IntelliSnap take snapshot on volume, then it triggers a SnapVault to a NearStore only for full backups (SnapLock configured), after this it takes backup copy for standard backup, where we have longer retention and possibility to restore single VM or single files….

In case of disaster, we can restore full backup volume via IntelliSnap restoration then we restore VM backups from the standard backup. This should be much faster as restore whole VM from VSA backups.

Question is will this work, or is there a thinking error.

we use :

v11sp28.36,

VM: indexversion 1

Regards Jürgen Budig

Beginning with ONTAP 9.13.1 ONTAP is able to create a FlexClone of SnapLock without inheriting retention-time from SnapLock volume.


You should be able to use NetApp FlexClone within Commvault also for NetApp SnapLock Volumes.


Hello @Damian Andre 

thanks for your answer.

Outside of this, the recovery of a full VM from intellisnap relates to mounting the snapshot and copying the data from the old to the new destination. The question is - what is copying the data here? Are we doing this on the array, independent of CV?

thanks

 

Sorry I didn't see your response notification. Generally you dont want to mount the original snap, register the VMX and run the VM because then you would be modifying your snapshot… you wont have the original data for that backup job anymore. So the point of the copy, is to mount the original snap, and copy it back on to the product datastore without modifying the source data.

When performing a live recovery operation, instead you can start the VM and perform a vmotion in the background to move the VM back into the right place. That snap mount is a clone of the original snap so the original remains in-tact


Hello @Damian Andre and @Juergen 

 

When this mount operations happens, is the snapshot that is mounted to the ESXi host now attached as a read/write volume?  Or a cloned volume?  If so, in theory one could register the .vmx file for the VM in vCenter, then power it on, right?  Once online, the VM can then be migrated using storage vmotion while on to a different datastore.  That could improve RTO for bringing the VM back online.

Thoughts on this?

For NetApp it should be a Cloned volume, not all snap engines support non-persistent mounts but NetApp does (and does it well) - You should be able to perform a live VM recovery from a NetApp snap automatically in the software. Its not as simple as registering the VMX as there could be clashes with existing VMs (say, if you wanted to restore a copy). But commvault should take care of all that as mentioned above:

https://documentation.commvault.com/2022e/essential/146297_live_recovery_for_vmware_restores.html

List of supported snap engines for live recovery from snap: https://documentation.commvault.com/2022e/expert/37177_intellisnap_support_for_live_vm_recovery.html


Hello @Damian Andre and @Juergen 

I’m also looking at options to improve our VM restore times using CommVault and our NetApp with intellisnap.

Regarding the comment: “Outside of this, the recovery of a full VM from intellisnap relates to mounting the snapshot and copying the data from the old to the new destination.”

When this mount operations happens, is the snapshot that is mounted to the ESXi host now attached as a read/write volume?  Or a cloned volume?  If so, in theory one could register the .vmx file for the VM in vCenter, then power it on, right?  Once online, the VM can then be migrated using storage vmotion while on to a different datastore.  That could improve RTO for bringing the VM back online.

Thoughts on this?


Hello @Damian Andre 

thanks for your answer.

Outside of this, the recovery of a full VM from intellisnap relates to mounting the snapshot and copying the data from the old to the new destination. The question is - what is copying the data here? Are we doing this on the array, independent of CV?

thanks

 


Hey @Juergen,

There is a lot here but I want to start with the objective of getting faster RTO.

IntelliSnap on VMware does not necessarily give you this. Backups are taken at the volume level, and for accelerated recovery you’d want to do a revert on the volume - however this would erase/recover all VMs on the same volume and hence this option is not allowed in the software - UNLESS your VM is running on an NFS datastore/volume on a NetApp array. This is the only configuration that allows for individual VM revert (outside of vSan). Outside of this, the recovery of a full VM from intellisnap relates to mounting the snapshot and copying the data from the old to the new destination. That may not be any quicker than restoring from backup storage.

For faster RTO you could leverage a VM replica (VM replication) or try live recovery from snap (which requires R/W to the snapshot so not sure that would work in your scenario).


Reply