#from target host# recover -s -c

To control metadata workflow, make also sure that is used in NSR client in field for backup server interface.

It's the same status. see below

C:\Users\Admserv>recover -s hefrbck06-226.sofr.hefr.lan -c hefrsql03.sofr.hefr.lan

No index was found for C:\Users\Admserv\. The current working directory is /.

recover>  cd u:\backup\bande

recover> changetime 06/24/2014

18361:recover: time changed to 06/24/2014 23:59:59 (mm/dd/yyyy)

recover> add SAFEQDB_backup_2014_06_23*.bak

1 file(s) marked for recovery

recover> recover

Recovering 1 file into its original location

Volumes needed (all near-line):

        USRS25L4 at SL500

Total estimated disk space needed for recover is 73 MB.

Requesting 1 file(s), this may take a while...

Recover start time: 7/10/2014 03:45:05p

Requesting 1 recover session(s) from server.

53363:recover: Recover of rsid 22353 failed: Port mapper failure - RPC receive operation failed

73724:recover: One or more recover threads failed to exit successfully

73731:recover: Parent recover thread exited with errors

52973:recover: Didn't recover requested file U:\backup\bande\SAFEQDB_backup_2014_06_23_012731_0331209.bak

Received 0 file(s) from NSR server `hefrbck06-226.hefr.ch'

Recover completion time: 7/10/2014 03:49:25p

recover>

In the Networker Server, the client hefrsql06.sofr.hefr.lan has the information for the field  named "server network interface" set to "hefrbck06-226.

More help, please.

It's not possible to use the Networker server to execute the restauration.Because it's not the same platform. Client run on Windows and the server on Solaris

Also, where are you trying to run the restore from. If you are trying this from the backup server give this a shot from the active node of your cluster.

nsrinfo hefrsql03.sofr.hefr.lan give a correct output with the contains of the backuped saveset, u:\backup\bande

hefrsql03.sofr.hefr.lan is one of all  virtual host of the cluster.

after anylase with my network administrator, the problem is the server use the wrong name to create the rpcbind session. Because on the server, there are 6 differents network ip. The networker server use the default network ip to open the rpcbind session but not the network ip in the same vlan of the client.

do you have a suggestion ?

Are you sure data is saved under cluster index?  You can check it with nsrinfo command (check it for both virtual and physical box).

it's the same IP address.

C:\Users\Admserv>nslookup

Default Server:  hefrns01.hefr.ch

Address:  160.98.2.110

> hefrbck06-226.hefr.ch

Server:  hefrns01.hefr.ch

Address:  160.98.2.110

Name:    hefrbck06-226.hefr.ch

Address:  160.98.226.191

> hefrbck06-226.sofr.hefr.lan

Server:  hefrns01.hefr.ch

Address:  160.98.2.110

Name:    hefrbck06-226.sofr.hefr.lan

Address:  160.98.226.191

> hefrbck06-226

Server:  hefrns01.hefr.ch

Address:  160.98.2.110

Name:    hefrbck06-226.sofr.hefr.lan

Address:  160.98.226.191

> 160.98.226.191

Server:  hefrns01.hefr.ch

Address:  160.98.2.110

Name:    hefrbck06-226.sofr.hefr.lan

Address:  160.98.226.191

>

on the recover prompt you have given "hefrbck06-226.sofr.hefr.lan" but then the recover fails it says "hefrbck06-226.hefr.ch". please check the hosts file entry or name resolution for these 2 names on the client.

Try using the IP address instead of the backup server hostname.

To me it looks like some sort of network issue when reading data from storage node back to client.  This is why you get RPC error after selecting data and kicking off restore.  Quick and dirty, you can try to restore it somewhere else too (also Windows box).  What you can also try is to sniff network between server<->client and storage node<->client to see which VLANs are used for communication.  Because metadata part works (which is browsing in this case), it might be that data plane is broken which is storage node communication back to client (is storage node for this client also on VLAN 226?)