Here is the situation :
- SMHV creates a snapshot with Snapdrive + VSS Writer of HyperV + Ontap Hardware Provider the LUN containing the snapshot.
- Snapdrive connect the LUN in the previous snapshots, thus creating a LUN Clone and apply the TxF recovery to NTFS that is in the LUN clone.
- Snapdrive creates a new snapshot after txF recovery and suffix it with _backup... So we have 2 snapshots per SMHV Backup
- BUT When we launch sdcli snapvault archive command after each snapshot, it looks like we are transferring the entire LUN clone instead of the supposed block delta. It looks like there is no optimization for the LUN clone transfers.
My questions are if you are sharing the same symptoms on :
- the backup duration : it takes 20 minutes between the first and second snapshot for SMHV backup;
- The snapvault transfer size : the entire LUN is transferred each time an snapvault update with Snapdrive is executed.
Couple of questions.
>>- the backup duration : it takes 20 minutes between the first and second snapshot for SMHV backup;
You mean to say that 20 minutes delay in transferring the data to snapvault secondary?
It was an bug in DataONTAP which transferes LUN and LUNclone as LUN instead of the changed block in the case of second.
I am not sure if this issue is now fixed, will try to dig out DataONTAP fixes regarding this,
This issue of vaulting lun clone as lun is fixed with Datontap burt
Which version of DataONTAP are you using? please check the target release of the burt.
That means autorecovery is taking 20 minutes in your system, at the end of the autorecovery we take the second snapshot.
We need to figure out why this is taking too much time, do you see any errors in the application event log
for the Hyper-V parent or inside the VM?
You also need to check the Hyper-V VMMS event log as well.
Snapdrive is getting faster now.
The Snapvault optimized mode is not working with snapdrive as the code doesn't include it.
If you want to use snapvault with SMHV you need to use API function with no-lun-clone-expansion = true with APItest from the NM SDK.
Request the snapvault secondary system to begin an incremental transfer to the given secondary path. This API is equivalent to the 'snapvault update' Data ONTAP command. It is required that this secondary path has already been configured as part of a snapvault relationship. The primary system and path configured in that relationship will be used as the source for this transfer. The request will only start the transfer and return. The actual transfer will proceed asynchronously and there is no guarantee that it will succeed. The snapvault-secondary-get-relationship-status API should be used to check the status of the update.
Input Name Range Type Description max-transfer-rate integer
The maximum transfer rate in kilobytes (1024 bytes) per second to be applied only for this update transfer. If this option is not provided the default behavior will be to allow the transfer to proceed as fast as possible. Range:[1.. 2^32-1] no-lun-clone-expansion boolean
This option dictates how a lun clone would be transferred from source to destination. If this option is "false", a LUN clone would be transferred as a LUN and if it is "true", it will be transferred as a clone. By default the value of the option is "false". primary-snapshot string
Name of the primary snapshot to be used for this update transfer. This option is supported for only Netapp primary systems. If this option is not provided, the primary system will create a new source snapshot for this transfer. secondary-path string The secondary path that will be used as the destination for this update transfer. It is required that this secondary path is already a part of some configured snapvault relationship.
apitest nacl4 root passwd snapvault-secondary-initiate-incremental-transfer primary-snapshot test secondary-path /vol/smhvmir/q1 no-lun-clone-expansion true
and I guess you need a loop to create a snapvault snapshot after the incremental update have finished (codes examples are existing like in sv-smvi).