Hallo Lynsey,
I am suffering from foot-in-mouth syndrome (or train-lag because I was
writing the message while travelling at 200Km/hour in a train). I forgot
that there is at least one situation where the domain account does play a
role and I completely forgot about it. Recoveries are ALWAYS done in the
context of the user logged on to the machine, this implies that the user
must have permission to recover files and directories. This plays an even
more important role with directed recoveries which should be clear by the
end of this message.
The problem with Networker is that the developers wear blindfolds most of
the time. Any time an unexpected return code is received from an API-call
they just pass the back to the user interface without even attempting to
analyse or recover.
The message "Network path was not found" is the text that the Win32 API
FormatMessage returns for the error code ERROR_BAD_NETPATH or 51 decimal.
But the question remains why this message is being displayed, and (see
above) where this message came from. It would be so helpful if the
developers would actually say where the problem occured, the message on it's
own is useless. Then it would be much easier to find what is causing the
problem.
To understand what might be the problem you have to know how recover
(command line) works and the difference between relocating and redirecting.
A recovery is normally done from the client with the recover command or the
GUI. If you use the GUI then the GUI communicates with the server to perform
the recovery, if you use the recover command then the recover command
communicates with the server. But the process will alway be in the context
of the user lgged on to the client.
The recover command has several options that can be used, one of these is
the automatic mode. If you execute recover in automatic mode then you
specify the owner (-c) of the data, where (-d) the files have to be placed
(relocate) and what (path) is to be recovered and which (-I) files. (Note:
The description of recover is confusing, read about -i first to understand
that -a more then one option). What the documentation does not tell you is
that the input (-I) can be read from the console (STDIN) by specifying "-"
instead of a file name.
The following command lines are examples (with some information such as date
etc missing):
recover -s host -c <client> -d D:\Temp C:\Temp
> add *
> recover
> quit
echo * > files.ini
recover -s host -c <client> -d D:\Temp -I files.ini C:\Temp
echo * | recover -s host -c <client> -d D:\Temp -I - -a C:\Temp
Please note the last example. This is where the file names are piped into
the recover using automatic mode.
The above examples show varies methodes to perform a recovery while logged
onto the client.
Now I can explain the the directed recovery method and why it will not work
for you. A directed recovery under Windows NT/2K can only be performed from
the GUI. The reason for this is that the GUI actually performs recovery in
automatic mode on the other client. The GUI is used to brows the client
index and to select files. The entries to be recovered are captured into a
file that will be used as input to the recover process that is started on
the client. Then the recover communicates with the server to recover the
files.
Very important: The remote client, where the recover is executed, assumes
that the GUI is executed on the server. (later).
To understand why it won't work you have to know how the GUI causes the
recovery to be started on the remote client.
The GUI performs the equivalent of the following commands:
SET RCMD=recover -s <server> -iY -t "05/04/2000 08:30" -c <client>
-I - -a
SET RUSER=ntimpersonate
SET NSR_MAST=Recover
..\nsr\bin\nsrexec -c <client> -f <recover entries>
The RCMD environment variable specifies the command to be executed on the
client. In this case the recover command uses automatic mode and expects the
entries to be recovered from STDIN.
The RUSER environment specifies how the authorisation is to be performed,
and this is the problem! The option ntimpersonate means that the remote
process (on the client) will impersonate the user executing the nsrexec.
This means that the remote client will try to change the context to the
account you have logged on with on the server. This implies that the account
you are using must be an administrative account on both systems.
The NSR_MAST environment variable seems to indicate that a recover is to be
performed (don't really know exactly).
The last line uses nsrexec on the local machine to contact nsrexecd on the
remote machine to execute the command in RCMD using the remote user
ntimpersonat with input from the file specified by -f to be piped to STDIN
on the remote machine.
The output of the remote process (STDOUT) is piped back to nsrexec and
printed on the console.
If you understand what actually happens then you can also see that it should
be possible to do a 3 party recovery by starting the recovery from another
client. This actually can be done but you have to specify the client running
the GUI must be entered in the servers file on the client.
As explained above, a cross domain directed recovery can not be performed
because the GUI uses an explicit impersonation which will fail. At the
moment I do not have a solution for this problem, except that you will have
to logon to the client to perform recoveries if they are within different
domains.
Bye
Ernie
-----Original Message-----
From: Lynsey Wyles [mailto:Lynsey_2_Wyles AT GSK DOT COM]
Sent: Tuesday, May 20, 2003 5:57 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] across domain recovery
Thank you Ernie for your detailed reply.
I am backing up the 'ALL' saveset for this particular client...so there is
no problem with what I'm backing up, and I was running a test recovery on
the c:\temp folder to recover it to d:\recover folder! so nothing unusual
here.
I am using networker user on the backup server and get this message during
a directed recovery to the client.
I have just run a recovery on the client itself, as you suggested, using
the Networker User and this has worked...so no problems here.
I just get the 'no network path when running a directed recovery on the
backup server.
Lynsey
That sounds quite normal to me: You must ask yourself why the message
"Network path was not found" is being displayed.
This message implies that you are doing something you should not be doing,
because Networker does not use a network path to backup or recover (unless
you did something the developers did not think of ;-).
Backups are always done through the nsrexecd service on the client. The
nsrexecd service runs under local system account and can only access the
file systems through the assigned drive letters. This implies that a backup
of a (remote) client will always backup the filesystems as if the backup
application runs on the client it self.
What might not be obvious is that Network NEVER uses a domain account !!!!
Therefor it is unimportant to which domain the server and the client
belongs. Also this does not have any influence on the recovery of
permissions because these are located within the backup file (ie blob) and
are recovered on the client (not server). Permissions (ACLS) contains a list
of SIDs and GIDs that are relative to the client SAM and domain SAM only.
If you receive this message during a recovery then it implies that you did
not backup the local drives using the drive letters but that an UNC name was
used instead (very bad practice) which can not be found or you are trying to
relocate the files to a network resource.
The important questions are:
What are the saveset (names) that were backed up ? Did you
use UNC
names and does the share still exist ?
What did you specify during the recovery ?
Are you doing a recovery from the server
instead of the
client with relocation of the files ?
The proper methodes for this type of recovery are:
1) Logon to the CLIENT and use WINWORKR or recover (.../nsr/bin/recover.exe)
to do a normal recovery.
2) Logon to the server and do a directed recovery (from client to client)
There is a third methode using another client but that is for the more
experienced because it involves changes to client and the server.
Bye
Ernie
-----Original Message-----
From: Lynsey Wyles [mailto:Lynsey_2_Wyles AT GSK DOT COM]
Sent: Tuesday, May 20, 2003 3:58 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: [Networker] across domain recovery
NT environment
I know Networker can handle backups of clients across different domains,
but I am trying to recover a file which backups up to a backup server
within domain A, the client being within domain B, of which I have
different accounts for.
recover a file back to the backup server, no problem
recover a file back to the client, Networker user comes back with: Network
path was not found.
Thanks for any help.
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
