NDMP is a backup control protocol, but it's not a data format. Even ONTAP has multiple formats for NDMP backups. In the first release of NDMP, the backup was a near mirror of ufsdump, and it was pretty easy to restore an ONTAP backup to something like Solaris. You'd get some weird permissions, but it did work.

The problem with ufsdump formats is the controller has to create the files and stream them off to the backup destination. About 10 years back, ONTAP added the ability to do NDMP backups using a snapmirror format. It was just the raw WAFL data, and it was WAY faster. It also meant that unless a system could real WAFL, there would be no way to use those backups. It was a nice option for full backups with a low chance of needing to be recovered, because recovery would requiring restoring the entire volume object that you backed up.

Snapdiff allows a backup application to do incremental-forever backups. It could ask ONTAP to identify changed files from the previous backup and provide the list of files to be backed up to the backup app, which would be read from an NFS/SMB share. I didn't think NDMP was involved.

Does the Rubrik documentation mention a NFS or SMB share path?

If the ONTAP system went away someday, I would expect you could use a Cloud Volumes ONTAP instance in Azure or AWS to restore the data. There used to be some sort of limitation with NDMP and CVO, but I can't see why Snapdiff wouldn't work as usual on CVO. I'll ping a couple of guys…