Hi Stefan!
Thank you for taking time to reply.
if there is any difference between backing up via storage snapshot integration vs using direct NFS backup, right?
Yes.
Because even der backup from storage snapshot will use NFS in your case as NFS is used to preset the volume to the NetApp.
That's what I'd assume too.
When backing up from a storage snapshot, I get log events of:
Using backup proxy VMware Backup Proxy for retrieving Hard Disk 1 data from storage snapshot on [name of NetApp cluster].
When backing up via NFS, I get log events of:
Failed to prepare VM for processing from storage snapshot, failing over to using VM snapshot.
Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nfs].
I've also had this job backup VMs via nbd. When this occurs, I get log events of:
Using backup proxy VMware Backup Proxy for disk Hard disk 1 [nbd]
So, when I stop backing up from a storage snapshot, how do I make sure the backup job backs up via nfs rather than nbd? I'm guessing the ndb backup is using NFS, yet it is so much slower because its going through the esxi hosts to perform the backup rather than communicating directly with the datastore. Correct?
The only way to enforce direct NFS over backup from storage snapshot using NFS is by disabling storage snapshot processing in your job settings as the job will then use the regular transport modes.
How?
The difference could only be that your system has somehow a policy in place that limits the processing rate in NetApp when reading from a snapshot vs the original volume.
Interesting theory. I know there is no policy like that when I log into the NetApp's system manager. However, I don't know enough about NetApp's management OS to state for certain that this could NOT be possible. (So, in other words, I guess it could be possible.)