Ontap Storage Integration skipped due failover to network

[MatzeB]

Hello all,

we have the following problem. We have two types of storage, both on the same netapp (different SVMs) attached via NFS. Once the "normal" server storage and one storage for the DMZ in a dedicated vlan. Our Veeam proxies have a network interface in the normal server storage, here we use Direct Storage Access/ Backup from Storage snapshots.
However, the proxies have no connection to the DMZ network as this is physically separated. This is intentionally, for the backup job it is ok for us if all DMZ VMs here failover to network and pull the data via ESX VMKernel management.
The backup job is configured with a SOBR as destination, as secondary destination we use "Ontap Snapshots" and "Ontap Snapvault". For the normal storage, the backup is written to the repository, an ontap snapshot is created and a snapmirror update is made.
For all DMZ Storage VMs, a failover to network occurs (as planned) and the data is successfully written to the repository. However, NO ontap snapshot is created and NO snapvault update is made. But there is no error/warning in the job. My expectation would be that despite failover to network storage snapshots/snapmirror updates are made. There is a second job (ontap snapshot only, without Repo) which works without problems for all VMs, because for storage orchestration management access is enough. So the problem seems to be the failover to network.

I have a technical support case open for it, case no. 04750409.
The support has confirmed: "If we don't have access to even one network, then we skip any storage integration-related operations by default."

To be honest, I quite don't understand the behavior. I would expect that the ontap snapshots and snapmirror updates are done as configured in the job. This would be technically possible, even without access to the NFS DMZ storage network, management access to netapp should be enough.
Even if the behavior is "by design" in Veeam, I have a problem with the error handling. In the job is clearly configured that storage snapshots (with retention) and a snapmirror update should be made. Although this does not happen the job is completed successfully, from my point of view this is a gab.

I would be interested to know how other people consider this issue and whether there are plans to change anything in the future.

Regards
Matze

[Adam.Bergh]

Hi Matthias, thank you for posting in the forums. After reading your post a few times, it seems like Veeam is doing the correct behavior here. You have two scenarios - one ONTAP integrated backup and one non-integrated NBD backup (DMZ). For your non-integrated NBD backup, you also want an ONTAP snapshot and snapvault update. The correct job configuration would be to separate out these in to two separate jobs, the NBD backup job (disable storage integrations in the advanced job settings, don't rely on failure). Create a second job that is "snapshot only" - meaning you leave the repository setting as ONTAP Snapshot and enable the snapvault.

Hope this helps. If you have any additional questions let me know. Thank you!

-Adam Bergh

[MatzeB]

Hi Adam,

thanks for the quick reply, I fully agree the topic / explanation is a bit tricky, so I completely understand if you have to read the text several times.
I am aware that we can solve the "problem" by a separate job. In fact, we will probably get a separate DMZ proxy, which will also solve the problem.

Still, I don't entirely agree with Veeam's behavior. There are clearly two options configured in the job, but they are not executed, without warning.

Let me give two more examples.
A job which only protects DMZ VMs, to repo, snapshot, snapmirror. Despite that the Snapshot and Snapmirror options fail for "all" VMs, since the job contains only DMZ VMs, the job is successfull, which i think is strange, because 2 of 3 options aren't executed.

Or another example, I have a DMZ proxy, the backup from storage snapshots works. Now by accident all VMs get a VMware snapshot which the admin created manually (for example for patching). As soon as a VM has a snapshot, a failover to network happens with direct NFS. This means that in this example no snapmirror update and snapshot is executed, although configured. I think this can not be the ambition of Veeam.

A small technical detail has still been noticed by me. If you configure Backup from Storage Snapshots + Ontap Snapshot Retention in the job, then two primary ontap snapshots are created. One to pull the data "Veeam_AUX..." and one to keep after retention. So from my point of view there is no technical reason to skip the storage integration when failover to network, it rather fails because of the current implementation of the logic.

I am well aware that there is no immediate solution, we were able to help ourselves with the workaround with two jobs. Nevertheless, i think it would make sense, to adjust this in feature releases.

Have a nice day!
Regards
Matze