Thanks, that worked. Unfortunately, I still can't recover the saveset and
I'm beginning to think all the savesets for this client are unrecoverable.
The reason I was trying to do a saveset recover is that when using the GUI
to recover files I check the files to be recovered then view the "Required
Volumes" before beginning the recover. The only thing listed in Required
Volumes is "unknown". I verified that I get these results for any recover
for this client and only this client.

Next, I used mminfo to find the ssid of the saveset containing the desired
files and attempted to recover it using the recover command. After finding
the correct recover command with help from this list I initiated the recover
using the saveset recover option and got continuos messages stating that the
backup server was unable to find the volume. No volume loads were ever
requested at the server .

The following was logged to the daemon.log:

04/15/03 10:44:46 ansrd: cannot look up save set for host pebble and
savetime 1049764744
04/15/03 10:44:46 ansrd: vol_attr, err: aggr_rlists: bad return from
vol_info
04/15/03 10:44:46 ansrd: Cannot find the volume needed

The problem may be in how this client was set up initially. It is an odd
situation in that this host has an interface in the DMZ and an interface in
the internal network. The internal interface resolves in dns to stone while
the DMZ interface resolves to pebble. This was really a bad idea and
objections were raised and over-ruled.

The following client setup modifications were required to allow backups to
complete for pebble:

The initial attempt to backup pebble just hung and eventually timed out. So
we

1. Added an entry to the backup server's hosts file for pebble's private DMZ
ip address.
(The initial attempt to backup pebble just hung and eventually timed out. So
we added the host entry.)

2. Added pebble.dcri.duke.edu as an alias in the networker client setup for
pebble.
(After adding the host entry we got this in the daemon.log:
* pebble:SYSTEM STATE:\ save: SYSTEM error: `pebble.dcri.duke.edu' is
not a registered client
* pebble:SYSTEM STATE:\ save: Cannot open save session with
cromite.dcri.duke.edu
Adding the alias corrected this.

3. Added *@stone.dcri.duke.edu to the remote access list for pebble.
(This was done because after adding the alias above we started getting this
message in the daemon log:
* pebble:SYSTEM STATE:\ save: RAP error: User SYSTEM on computer
stone.dcri.duke.edu is not on pebble's remote access list
* pebble:SYSTEM STATE:\ save: Cannot open save session with
cromite.dcri.duke.edu

At this point the client backup worked normally.

Can anyone suggest any alternate methods of recovering savesets for this
client?

Thanks,
Vic







> ----------
> From:         Stan Horwitz[SMTP:stan AT temple DOT edu]
> Sent:         Monday, April 14, 2003 3:52 PM
> To:   Legato NetWorker discussion; Engle, Vic
> Subject:      Re: [Networker] Windows SSID recovery
>
>
>
> On Mon, 14 Apr 2003, Engle, Vic wrote:
>
> >Hello List,
> >
> >I would like to recover an SSID for a windows box. My networker server is
> >Solaris 2.6 running networker 6.1.2 on a Sun E250.
> >
> >I can't seem to recover the windows ssid to the unix server and the
> windows
> >version of "recover" doesn't seem to have the same functionality as the
> Unix
> >version.
> >
> >Is it possible to recover a ssid from a windows command line?
>
> Yes, the Windows recover has the same functionality as the Unix
> version, but you need to be sure you're actually using the Windows
> NSR recover and not the recover that comes with Windows. To do this,
> change directories into "Program Files"/nsr/bin before you begin
> recovering files.
>

--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=