NDMP backup not working for new Networker installation.

Please consider moving this question as-is (no need to recreate) to the proper forum for maximum visibility.  Questions written to the users' own "Discussions" space don't get the same amount of attention and can go unanswered for a long time.

You can do so by selecting "Move" under ACTIONS along the upper-right.  Then search and select: "NetWorker Support Forum".

Thanks Christopher, I have moved to Networker support forum.

We have struggled with implementing our NDMP (NetApp) Backup as well. We are using NDMP-DSA like described in the Admin Guide (8.0.1) under "Sending NDMP data to non-NDMP devices that reside on a NetWorker storage node"

From the documentation it seemed that port 10000 needs to be opened between the NetApp and the NetWorker Server only, but it needs to be opened between the storage node and the NetApp as well.

Our current Backup command is: nsrndmp_save -T dump -M -P

It spawns the nsrdsa_save process on the storage node. If you have configured your networker server as the storage node, you will see the process starting on your networker server. try to run the nsrndmp_save command directly from the storage node in order to prove if it is working.

Make sure that communication paths are well configured between the filer, storage node and networker server and all the required firewall ports are open. Use the same port range (nsrports) on both your servers (nsr and storage nodes) and clients.

Regards

Christian

The error posted by OP seems to suggest wrong backup command or save set (do not use All with VNX/Celerra).

Strangly, the NDMP backup is working from command line when we run the command from Storage Node.

However, the same NDMP backup wouldn't run from NMC.

Has anyone faced this kind of issue earlier ?

Because one more instance where I have seen this was when server primary interface was not vlan available on filer and then DSA process on storage node would be started against that interface, but filer would not be able to communicate - it is fairly documented issue which has been debated several times on this forum.  Not sure if recent versions brought any change. With just one VLAN, you should not experience that kind of issue of course so I guess that's not your issue.

Networker server was having multiple NICs. However due to this NDMP issue, we have disabled one of the NIC. Now backup is happening through single NIC.

Are your boxes multihomed?

Have you checked that the storage node and celerra can communicate over port 10000? Does the storage node and the celerra share a NIC within the same LAN/VLAN?

42573:savefs: Error reading. System Error: An existing connection was forcibly closed by the remote host.

Above error related to network as well as firewall.

NetWorker uses persistent
connections between daemons to transfer information as efficiently as possible.
Connections are opened at the start of communication, and closed when
communication is finished. For example, a running backup may have connections open
to a nsrmmd with the backup data, nsrindexd with client file index information,
and to nsrjobd for control and status information.

However, if a firewall arbitrarily cuts connections that seem idle, there will be a network
error (transport layer problem) to NetWorker,

To prevent these problems, configure the firewall to not close idle connections, or have
an operating system timeout long enough to accommodate the backup window.

The status connection to nsrjobd is frequently idle for most of the backup: if there are no error
messages to report, the connection will not have traffic until the success
message when the backup is done. As a result, this connection is the most
common connection to be cut by an aggressive firewall.

If it is impossible to eliminate a firewall timeout, change the operating system's TCP
keepalive interval on each machine if connections to other daemons time out.

>>>>42596:savefs: get fs info: communication failure.

>>>>90068:savefs: There is nothing to save.

check nslookup for that host, if it will show the second local name, then add in alises with your backup client FQDN.

nslookup "backup client fqdn"

And start the backup

Hi All,

Thank you for responses. the issue is resolved now. The issue was with HP teaming. Apparantly, the teaming was not working well. We have now disabled the teaming and it is working fine.