Video Screencast Help

NDMP with NetApp cDOT (Cluster-Mode)

Created: 22 Jun 2014 • Updated: 29 Jul 2014 | 15 comments

Has anyone had success in BackupExec 2012 or 2014 in backing up via NDMP a NetApp filer running cDOT (Cluster-Mode) 8.2 or higher? We have an open case with support when running 2014+cDOT 8.2.1 where we cannot browse any snapshots and/or files within our volumes when connecting to our filers, something we were able to do with 7-Mode.


Operating Systems:

Comments 15 CommentsJump to latest comment

Colin Weaver's picture

Page 127 of the BE 2014 HCL states:


NetApp clustered data ONTAP (CDOT) features such as service name virtualization and multi-tenancy (VSERVER) capabilities are not supported


As we do support cluster mode, these limitations apply to specific configurations


Are you using these features?



reuvygroovy's picture

I am well aware that you don't support cluster-aware backup and vservers. I am talking about more basic functionality, as you pointed out, like just backing up a snapshot.

We noticed that in cDOT we cannot view any of the object within our volumes, such as LUNs and/or snapshots, something quite trivial and basic to the NDMP backup process. We spoke to support about it, and they claim that it's because we are running 8.2.1, and only 8.2 is listed in the matrix. But it's hard for us to believe since 8.2.1 (as opposed to 8.2) is a minor build, and it's hard to image something so basic has changed since then. Therefore we are asking the support wide forums to see if anyone has had any similar experience in 2014 with cDOT at all, to at least know that we're comparing apples to apples.

Colin Weaver's picture

Whilst we usually don't expect dot revisions to badly effect the operation of Backup Exec, there have been occasions in the past when they have, as such it is probably a good idea to ask if anyone else has either a) seen it work or b) got the same problem.

For info we have seen similar symptons described when someone was using a VSERVER implementation which is why I pointed out the limitation

Colin Weaver's picture

For info, unless there is a second customer reporting the same condition, there is an internal thread discussing this scenario which I suspect relates to your support case. I am awaiting cofirmation of when the change occurred,  but it appears that something Backup Exec relies on to enumerate NDMP selections has been dropped from c-Mode cluster support in the newer version(s) of OnTap


If it is your support case you'll probably have the same info already. However when I get a bit more detail I will update.


reuvygroovy's picture

Hi Colin,

Indeed the response we received was that this issue is due to a limitation from NetApp side which does not allow BE to use an extension to browse the volumes to show files and folders.

So right now we're stuck with no (simple) way to backup NDMP. :-(



reuvygroovy's picture

I agree, which is why I am writing to the forums with the following questions:

  1. Has anyone been able at all with BE 2012 or 2014 to view snapshots on a cDOT filer?
  2. What version of BE and cDOT are you running?


icttpz's picture


same issue here cDOT 8.2.1 and BE 2014 latest patches and hotfixes. I configured the filer using the following symantec kb article.

Yes the article is related to NetBackup but it is a very good starting point to get the NetApp Filer correctly configured for Node-Scoped NDMP.

This way I can add the attached IBM TS3100 Tape Library and drive to BE 2014. But I have the same issue when trying to browse the volumes. No snapshots are listed.

Any news on this issue?

reuvygroovy's picture

From my post on the NetApp Communities:

Right now Symantec tell us that they know about the issue, and indeed there is no GUI method of selecting individual snapshots. They claim that NetApp has changed something in the API which they use in order to read the objects from the filer, which explains the behavior. We have been waiting for a few weeks now for a response on whether or not there is planned future support for this capability or not. They told us they are checking with their developers for this information, a process which so far has been long and arduous. I will try to keep you posted, if and when we get any further information.

icttpz's picture

Thanks a lot for the quick reply. :)


You say "no GUI method of selecting individual snapshots", does this mean I can use the Include/Exlude feature?

reuvygroovy's picture

Sorry about that. You can include/exclue - yes, that is in fact the only way. After selection the volume on the left-pane, you then write in the Path textbox:


Then, after the backup starts, you can use the following commands on the filer to view if in fact you are backing up the snapshot you hope to backup:

run * backup status 0


And then run this command to check for tape throughput on the filer:

run -node [nodeName] -command sysstat -t 1

icttpz's picture

Great. I will give it a try.

icttpz's picture

Worked. Now I just have to figure out how to restore it and have Netapp fix the VSC 5.x -> Snapvault issue and I'm set. :)

reuvygroovy's picture

These updates hot off the press:

1. Symantec tells us that they don't plan on fixing this issue, and are waiting for NetApp to fix this

2. We noticed that when you go to an existing selection list, when you try to view the configurations you et a popup warning you that the path entered is unrecognized or not OK, and then are asked whether or not to save the changes. After you select No and try to rerun a backup, it will fail, and if you look in the debug logs you will see the same parsing error that you get when trying to view the snapshots listed in the volume. The solution, if I can call it that, is to recreate the selection list from scratch.

We are currently testing if we modify the selections list via powershell if the same behavior occurs.

reuvygroovy's picture


1. We are still working with Symantec support on the problem where you cannot modify a selection list with cDOT snapshots.

2. We have discovered an issue where verifiying an NDMP backup causes the source LUN to be offline and/or innaccessible and/or not respond. We have reproduced the error and plan to inform Symantec shortly.