Force redirected NDMP restore to use correct media server

[jim_dalton]

We are restoring some netapp written tapes to a netapp simulator with a different target directory. Simulator has no tape drives. It all worked perfectly.

Then we properly retired the netapp leaving us with the simulator which then needed rebuilding.

Now when I try and restore to the simulator I have a problem in that the restore tries to use an ndmp host ( EMC) and we know that wont work, we want to force it to do a 3 way so it goes via the tape drives on the master with the netapp simulator does the decoding of the traffic.

06/03/2016 16:33:23 - Info bptm (pid=15852) INF - Waiting for mount of media id 004 on server master for reading.
06/03 /2016 16:33:23 - Error ndmpagent (pid=15869) failed to connect to NDMP server wronghost.us onnect error = -1,003 (Unable to connect to NDMP server)
06/03/2016 16:33:23 - Error ndmpagent (pid=15869) NDMP restore failed from path UNKNOWN
06/03/2016 16:33:23 - Error bptm (pid=15852) Unexpected NDMP message - not a connected message

wronghost.us is another (unused as it happens) ndmp hostname. Cant even see where it grabs this from!

Comms to netapp simulator are perfectly functional. Media has been assigned to master server.

Sol10 7604 master.

Your input appreciated,thanks Jim.

[mnolan · Accepted solution]

Actually going to another filer *would* be a 3way restore and for this, going to the master would be a remote restore.

There is a setting you can change using the nbemmcmd command.

PREFER_NDMP_PATH_FOR_RESTORE 0|1|no|yes

You can try setting this to 0 (or no) to see if that changes the behavior of tape drive selection.

This is of course assuming that a NetBackup media server (or the master) has the same tape drives from the library that has the tape.

https://www.veritas.com/support/en_US/article.000093192

[jim_dalton]

It does change the behaviour...it now has not failed immediately and appears to be working.

Must remember to revert...Im curious to know how we ended up here as it used to work.

Marked as solution.

Many thanks, Jim.