Logon Failure: when trying a Directed Recover

[itcxd]

Hi,

We have a central Legato Networker Server which backs up various clients, I am trying to complete a directed recover to one of the clients. I select the data I want and it trys to begin the restore, as soon as it begins it stops with error message.

Logon Failure: Unknown username or bad password.

Does anyone know what this Login Failure refers to?

To get around this I can restore the files to the local (Central) Legato Server and ftp the files to the correct Server.

Thanks,
Jo,

 

[605]

Strange. However, do not forget that the destination client also listens to the machine where you start the recover process. Extend the file /nsr/res/servers and restart nsrexecd.

 

[rstang]

Hi,

the problem is most likely related to access rights.
To perform a directed recover, the client the data goes to needs to have access to the files of the system the data originally belongs to and administrative rights on the NetWorker server.

Depending on the OS the server and clients are running, you have to add the OS account used for backups on the destination client to the administrators list on the source client and the NetWorker server.

To make it as simple as possible, I use the same account with the same password for backup on all clients, and on the NetWorker server I define <user>@* as administrator. This is not the most secure way, but works fine for me.

Hope it helps...

Regards
Ruediger

 

[605]

I do not think that the access rights are the problem. If this would be the case, then selecting of the files would not even be possible.

 

[wallace88]

Try the following:

1) edit the client resource of the client where the data was backed up *from*. In the remote access field, put: *@*

2) edit the client resource of the client where the data is going to. In the remote access field, put: *@*

3) Edit the server setup and add *@* to the list.

4) In command line, change directory to where the NetWorker binaries are located. In Windows, this is nsr\bin.

5) If you start the recover on the destination client, then run:

recover -s (server name) -c (source client) -d (temp directory) -t (recover date) -f -a (file spec that you want to recover)

(recover date is formatted: mm/dd/yy)


6) If you are starting the recover from the backup server, then run:

recover -f -R (Destination client) -c (source client) -d (temp directory) -t (recover date) -s (server name) (file spec that you want to recover)


Once this is done, and if it works, then remove the *@* from the administrator list and from the remote access list of the clients.

If it doesn't work, then show us the output.

 

[wallace88]

opps... in step 3, add *@* to the server's administrator list....

 

[wallace88]

Is the backup server and clients Windows based? If so, then:

- where are you starting the recover from?
- what account did you log in with?
- did you use local administrator account or domain administrator account? Try logging into both and seeing recovery works.

Reasoning: if you are starting the recover from the backup server, you could be using an account that is local to the b/u server. This is probably why you don't have problems recovering to the backup server.

The domain administrator should have sufficent rights to access any system in the domain.

If you start the recovery from the destination client, and if the remote access and administrator list is set up with *@* as mentioned earlier, and assuming that the account you are using has sufficient rights to write the data to the file system... then it should work.