Status: 02.09.2026
Tested with: Veeam Backup & Replication 13.1 and NetApp ONTAP Plug-in 2.0.14
Spoiler: Yes, coexistence works. But randomly clicking around is not a good idea.
 

Anyone who has known me for a while knows that I started in IT as a System Engineer back in 2005 — and since then, NetApp systems have regularly crossed my path. Or maybe I crossed theirs. Depending on perspective.

Over the years, I have built, configured, troubleshot, and occasionally lovingly cursed at NetApp systems in small, medium-sized, and very large environments. I had the chance to gain field experience worldwide, later trained people on NetApp while still implementing them in costumer projects, and was also involved with the topic strategically as a Head Architect and Product Manager/Director.

Long story short: I have a certain historical affinity for NetApp systems. Even though I no longer deploy them on a daily basis, my inner storage heart still gives a little twitch whenever snapmirror, igroup, FlexClone, or volume show appears somewhere.

So I was even more excited when the new NetApp ONTAP Plug-in for Veeam Backup & Replication was released.

So: pour coffee, boot up the lab, calibrate the mouse — and start testing.

 

What Is This About?

With Veeam Backup & Replication 13.1, there is a new NetApp ONTAP Plug-in based on the Veeam Universal Storage API.

According to KB4904, this plug-in uses the Universal Storage API to allow storage vendors to integrate their systems with Veeam for backup and restore operations.

Important: The new plug-in does not automatically replace everything the existing built-in NetApp integration used to do. However, it is now possible to backup your vsphere VM environment with netapp storage integration in the VSA as well. But only the VM envrionment. Because as of today:

• The new NetApp ONTAP Plug-in is intended for VMware / block / file storage integration only.
• NAS Backup / Unstructured Data Backup continues to use the built-in integration for now.
• Coexistence is possible, but only when cleanly separated by storage role. This makes it possible to use both workloads with NetApp integration via VSA.

Or, to put it differently:

The new plug-in gets VMware.
The built-in integration keeps NAS for now.
And if both try to grab the same cookie from the same jar, trouble starts.

Official Basis and Important Requirements

According to KB4904 NetApp ONTAP Plug-in v2.0.14 requires at least:

• Veeam Backup & Replication 13.1.0.411
• Supported NetApp systems:
  • NetApp FAS
  • AFF
  • ASA
  • ASA r2
• ONTAP 9.10.1 or later
• A valid FlexClone license is required, otherwise backup and restore tasks may fail.

IMPORTANT: These are not “nice to have” items. These are must-haves.
 

Fun anecdote: Did you know that NetApp’s file system is called WAFL, which stands for Write Anywhere File Layout? Because of that, some NetApp techies affectionately refer to storage “nodes” as toasters.

Lab Test: NetApp LabOnDemand as a Playground

If you want to test this and do not have a test NetApp or a dedicated lab environment available, you can use the official NetApp LabOnDemand environment.
 

You will need a NetApp account:
https://labondemand.netapp.com/catalog

A small warning upfront: In my test, the environment was still based on Veeam v13.0 and the classic built-in integration. This means that if you want to test the new plug-in with Veeam 13.1, you need to bring some time and patience.
 

In my case, that meant:

• Updating Veeam ONE
• Updating Veeam Enterprise Manager
• Upgrading Veeam Backup & Replication to 13.1
• Upgrading the Veeam Console to 13.1
• Building a classic test state:
  • Snapshot-only job with built-in integration
  • Backup job with Backup from Storage Snapshots (BfSS)
  • Do not forget the secondary destination in the jobs (SnapMirror / SnapVault)
  • Let the jobs run once cleanly and verify that everything was actually executed
• Only then install the NetApp ONTAP Plug-in
   

Why all this effort?

Because I wanted to reproduce the migration as realistically as possible. In other words:

“What happens if jobs, snapshots, and storage integration already exist?”
Basically, simulating a real live system on a costumer site.

The Actual Work: Migrating to the New NetApp ONTAP Plug-in

Step 1: Disarm the Old Jobs

Before you unleash the new plug-in on the same clusters or SVMs in production, you need to cleanly remove the old built-in integration from the jobs.

This is important because, according to KB4904, Veeam does not allow the same cluster or the same SVM with the same storage role to be used simultaneously through both the built-in integration and the USAPI plug-in.

So what should you do?

Review and disable all backup jobs using NetApp Storage Integration.

Check whether you have documented all Storage Integration jobs with all their settings. Since you are about to disable or delete the configuration, document it in detail beforehand if you have not already done so.
 

Then edit the jobs:

Disable Backup from Storage Snapshots

„Path: Edit Job -> Storage -> „Advanced job settings… “ -> Integration -> „

Remove the checkbox for: Enable backup from storage snapshot

Disable Secondary Destination

If you use SnapMirror or SnapVault as a secondary destination, you also need to disable this now:
Edit Job -> Storage -> Configure secondary destinations for this job

Again, remove the checkbox or remove the configuration.

Snapshot-only Jobs

If there are pure snapshot-only jobs using the old built-in integration, they must be deleted and later recreated using the new plug-in.

Yes, this feels a bit like “let’s take everything apart first.”
But it prevents Veeam from complaining in the next step because VMware jobs and objects are still holding on to the built-in plug-in.
 

Step 2: Remove the VMware Role from the Built-in Integration

Now go to the Veeam Storage Integration area: Storage Infrastructure -> ONTAP

There you should see your NetApp clusters, SVMs, or individual storage systems that were added through the built-in integration.
 

Case 1: Pure VMware SVMs

If these are SVMs or entire NetApp clusters used exclusively for VMware: Rightclick on Storage -> „Remove Storage“

However, this only works if no jobs are using these storage objects anymore.

So if Veeam complains: do not curse at it. Veeam is probably right. Somewhere, there is still a job, mapping, or storage reference attached to it.

Case 2: Mixed Cluster / Mixed SVM

If you have a cluster that provides both VMware storage and NAS backup, do not simply delete everything.

Instead: Rightclick on Storage -> „Edit Storage…“

In the first wizard window, remove the checkbox for: „Block or file storage for VMware vSphere„

Then complete the wizard with Finish and wait.
 

You need to do this for all relevant NetApp systems.

The result should be:

• The built-in integration remains responsible for NAS.
• The VMware storage role is removed from the built-in integration.
• There is no longer any backup job using the NetApp integration for vSphere.
   

Step 3: Add NetApp ONTAP Through the New Plug-in

Now comes one of the points that briefly confused me.

The important thing is where you click.

Go to the left side and click: Storage Infrastructure
 

Really click the top-level Storage Infrastructure node.

Do not click:

Because if you click ONTAP, or if ONTAP is selected when you click Add Storage in the menu, you start the wizard for the classic built-in integration. But we want the plug-in wizard.

If you are in the right place, the Add Storage wizard will show vendors such as:

• Cisco HyperFlex
• Dell Technologies
• Hewlett Packard Enterprise
• NetApp
• and so on

Then select the sixth item from the top: „NetApp – Adds NetApp ONTAP or NetApp Element (SolidFire) storage„

After that, select:: „ONTAP (plug-in)“ auswählen.

Now enter the FQDN:

• either of the NetApp cluster
• or of an individual SVM

REMEMBER if you add it with the VBR VSA the FQDN needs to be in the format username@domain
If you are using windows it can be either username@domain or Domain\username
 

Cluster or SVM?

This is where you need to think for a moment. Personally, I would almost always add the cluster, unless you have good reasons not to.

If you add the full cluster, you have more options and can also control SnapMirror/SnapVault.

If you only add individual SVMs, that may make sense depending on your architecture — but then you cannot manage/control cross-cluster SnapMirror/SnapVault relationships.

But this should be obvious to NetApp technicians anyway. It has always been like that.

My personal rule of thumb:

I would always add the cluster.
Unless there are reasons such as multi-tenancy in the cluster.

Then enable: „Block or file storage for VMware vSphere“ aktivieren

Enter credentials.

Select protocols:

• iSCSI
• NFS

Depending on how your environment is built.

Then select the Mount Server, proxies, and Linux mount configuration according to your environment.

After that: Finish.

And now take a deep breath. Enjoy your coffee or get a second cup.

Storage discovery is not a Formula 1 discipline.

Step 4: Recreate or Cleanly Convert the Backup Job with BfSS

Now first create a new backup job with Backup from Storage Snapshots.

Whether you reconfigure the old job or create a new one is up to you.

From a migration and troubleshooting perspective, I am a fan of:

Build new and test.

Especially because, currently, when switching from built-in to USAPI, existing snapshot retention information is not simply carried over.

Status: VBR 13.1 with USAPI v2.0.14.

So:

• Create job.
• Select VMs.
• Enable Storage Integration.
• Enable Backup from Storage Snapshots.
• Configure Secondary Destination if required.
• Run the job.
• Check logs.
• Check restore points.
• If SnapMirror/SnapVault is used: check replication and target snapshots.

Do not just read “Success” and be happy.

Really verify that what happened is what you think should have happened.

And don’t forget the test restores.

Step 5: Create Snapshot-only Jobs

If you use snapshot-only jobs, recreate them now through the NetApp ONTAP Plug-in.

Depending on your requirements, with:

• local snapshots only
• Secondary Destination
• SnapMirror / SnapVault
• Tamperproof Snapshots
• different retention targets

Especially with Tamperproof Snapshots, it is worth taking a close look at KB4904.

Important according to the KB:

• Tamperproof Snapshots are not supported on ASA r2.
• They are only supported if the entire cluster has been added to Veeam.
• Individual SVMs are not supported for this.
• ONTAP 9.12.1 or later is required.
• For SnapMirror Synchronous, ONTAP 9.19.1 or later is required.
• A SnapLock license is also required.

Or in short:

Tamperproof is cool.
But read the KB and pay attention to the dependencies.

Step 6: Clean Up Old Snapshots from the Built-in Era

Now comes a point that was important in my test and is also often forgotten in practice — until it potentially resurfaces later in a rather unpleasant way: when the storage fills up.

The old snapshots that were still created through the built-in integration were still visible in Veeam and could still be used for restores.

But they are not automatically cleaned up by the new jobs.

KB4904 says this as well, of course.

That means in practice:

Plan a controlled cleanup window.

Do not immediately delete everything if you still have restore requirements. But also do not forget that old snapshots consume storage space and, depending on your environment, may affect SnapMirror, retention, or compliance configurations.

You can clean them up, for example:

• through the Veeam GUI
• or directly through the NetApp CLI

If you clean up directly on the NetApp side, use commands such as: „snapshot show“ „snapshot delete“ with the correct vserver and volume.

And if you know what you are doing, you can also work with snapshot names and patterns like *Veeam*.

If you are not sure, get a professional involved or delete snapshots individually.

After that, do not forget in Veeam: Rightclick on Storage –> Rescan

Because Veeam can only display cleanly what it discovers cleanly after the rescan.

Step 7: Be Happy

If everything runs cleanly, you now have a nice target architecture:

Or, in storage nerd language:

The new plug-in plays the VMware melody.
The built-in integration keeps playing the NAS bass.
And if both stay in sync, the setup actually sounds pretty good.

Important Limitations

Please read KB4904 carefully before implementing this in production.

Some topics are especially important.

Coexistence of Built-in and Plug-in

According to KB4904:

• The same cluster or the same SVM must not be used simultaneously with the same storage role through both built-in and USAPI integration.
• Coexistence is possible if different storage roles are used.
  • Built-in Integration for NAS
  • USAPI Plug-in for VMware

Replication

Replication relationships between systems added through different integration types are not supported.

This means:

If SnapMirror/SnapVault is involved, all participating clusters should use the same integration type.

Other Important Points from KB4904

• MetroCluster / SVM-DR / SnapMirror Active Sync — No support for backup from secondary storage snapshots or snapshot orchestration on the secondary array. Primary-side backups may still be possible.
• ASA r2 Consistency Groups — With CG-level replication, the shortest retention of a job can limit the effective retention for all volumes in the Consistency Group.
• NFS considerations — The plug-in uses temporary export policies for auxiliary clones. Root volume export permissions of the SVM may need to be set manually or automated through an advanced setting.
• Advanced Settings file Depending on the platform, the advanced settings file exists on Windows or VSA/Linux and can be adjusted, for example, for NFS export rules or storage efficiency wait times.

https://www.veeam.com/kb4904

Important Learnings from My Test
 

1. Coexistence Works

Yes, the built-in integration and the new plug-in can coexist.

But not like this:

“I’ll just add everything everywhere. What could possibly go wrong?”

Instead, they must be cleanly separated by storage role.
 

2. The Order Matters

The order should be:

1. Disarm jobs.
2. Remove the old storage role.
3. Add the new plug-in.
4. Build new jobs or convert existing ones intentionally.

Not the other way around.

Otherwise, you will very likely end up in a state where Veeam tells you that something is still in use — and then you get to play detective.
 

3. The Menu Can Be Confusing

The Storage Infrastructure section is powerful, but you need to know where to click.

It makes a difference whether you click „Storage Infrastructure“, „ONTAP“, „NetApp ONTAP (plug-in)“

I created this picture to help you, so that you are not making the same mistake:

This is logical once you understand it.

Before that, it briefly feels like a 90s adventure game:

“You cannot use this item here.”

4. Advanced Settings Exist

There is an advanced configuration for the plug-in.

According to KB4904, the file is located in different places depending on the backup server type.

Windows Server: C:\ProgramData\Veeam\Storage\NetApp ONTAP\storage_plugin_advanced_settings.json

VSA: /etc/veeam/plugins/storages/netapp-ontap/storage_plugin_advanced_settings.json

Certain parameters can be adjusted there, for example around NFS export rules or wait times for storage efficiency / deduplication on SnapMirror targets.

Again:

Do not just change values because JSON looks nice.
Understand first, then change, then test, then document.

5. Do Not Forget Old Snapshots

Snapshots from the built-in world do not magically become happy USAPI snapshots with new retention.

Plan and monitor this actively, and do not forget cleanup. Eventually every storage system fills up, and then things become unpleasant.

My Conclusion

I find it exciting that NetApp ONTAP can now be integrated through the new Veeam plug-in based on the Universal Storage API.

To me, this feels like a sensible step because storage integrations become more modular and hopefully can evolve faster in the future.

As of today, however, you need to plan carefully:

• Which storage role is located where?
• Which jobs use which integration?
• Which snapshots already exist?
• Which replication relationships exist?
• Do I need NAS backup?
• Do I use MetroCluster, SVM-DR, or SnapMirror Active Sync?
• Do I want Tamperproof Snapshots?
• Did I add clusters or individual SVMs?

This is not a “Next, Next, Finish” topic for Friday at 4:30 PM.

It is more like:

Monday morning.
Coffee.
Everything read and understood beforehand.
Change window.
Documentation open.
KB4904 next to you.
NetApp CLI ready.

And now the most important question:

Who of you is already using the new NetApp ONTAP Plug-in?
Who has tested it in the lab?
What is your take on it?

I am curious to see where the feature set of the plug-in is headed.

My inner storage nerd is definitely watching with interest.

With good coffee. And probably with snapmirror show somewhere in the back of his mind.

Sources / Status

• Veeam KB4904 — Release Information for NetApp ONTAP Plug-In for Veeam Backup & Replication
  https://www.veeam.com/kb4904
• Veeam Help Center — Universal Storage API Integrated Systems
  https://helpcenter.veeam.com/docs/vbr/userguide/universal_storage_integration_api.html
• Veeam Help Center — Adding Universal Storage API Integrated Systems
  https://helpcenter.veeam.com/docs/vbr/userguide/usais_add.html
• NetApp LabOnDemand Lab:
  https://labondemand.netapp.com/