NDMPCOPY from cDOT (source) to 7DOT (destination) problem

[bbjholcomb]

The manuals I read said to issue the ndmpcopy command on the 7DOT filer.

The command:

     ndmpcopy -d –sa ndmpusr1:somepass –st text –da ndmpusr2:sompass –dt text xx.xx.xx.xx:/codt_volname/qtree01  xx.xx.xx.xx:/vol/7dot_volname/qtree01

The results

     Ndmpcopy: Starting copy [ 26 ] ...

     Ndmpcopy: xx.xx.xx.xx: Notify: Connection established

     Ndmpcopy: xx.xx.xx.xx: Notify: Connection established

     Ndmpcopy: xx.xx.xx.xx: Connect: Authentication successful (cDOT)

     Ndmpcopy: xx.xx.xx.xx: Connect: Authentication successful (7DOT)

     Ndmpcopy: xx.xx.xx.xx: Log: DATA: Backup terminated:  Unable to lookup Volume '/cdot_volname/qtree01': MGWD Server return failure for VserverNameToId (for /cdot_volname/qtree01)

The QTREE was created on the cDOT system, no data in the volume (new).

[parisi]

You need to specify the vserver name.

     ndmpcopy -d –sa ndmpusr1:somepass –st text –da ndmpusr2:sompass –dt text xx.xx.xx.xx:/vservername/codt_volname/qtree01  xx.xx.xx.xx:/vol/7dot_volname/qtree01

https://kb.netapp.com/support/index?page=content&id=3011297

[bbjholcomb]

Thanks, I tried that:

     Ndmpcopy: xx.xx.xx.xx: Log: DATA: Backup terminated: Backup of non-local Volume '/vserver_name/cdot_volname/qtree01' not supported (for /vservername/cdot_volname/qtree01)

I believe that NDMP is supported as a migration tool to copy data from 7DOT. Is it supported to go the other direction? Should I do the ndmpcopy from the cDOT system? I will try t.

[parisi]

Non-local suggests that you are issuing the command from a node that does not own the volume/qtree you are copying. Try to issue the command from the node that owns the volume/qtree, using a LIF/IP that is local to that node.

[loudymanschwab]

I've found the easiest way is to use the vserver management LIF of the node that the volume resides as your source hostname/IP.  However, this is assuming you made one (not really standard recommendation until 8.2+).  If you are using your cluster management LIF name or IP, then move it over to the node that hosts the source volume/aggr.

There are a bunch of other quirks you can run into, like whether the ndmp account you are using is a cluster or vserver level account.  But since your authentication is successful, and it's just complaining about volume ownership, I would just worry about LIF location first.

For some reason, I have never been able to successfully use a cluster vserver/svm level account to authenticate to a data or intercluster LIF for ndmpcopies.