That all sounds logical. I guess it would be interesting to see, though,
if the id really did need to be the same for the recovery to work,
assuming you had the luxury of time to screw around. Certainly, it would
appear that you need to create the client, but whether in fact its id
would *HAVE* to match is something that I guess I'd need to test. Of
course, since it's trivial to make it match, there really isn't any
reason I can afford that you should not go ahead and do it. Having a
mismatch could be tugging on Superman's cape. Having the id match,
however, seems like less of a tug.

George

Tim Mooney wrote:
>
> In regard to: Re: [Networker] Client id -- final question and 2...:
>
> > Ah, that's pretty slick, Tim, since the server normally complains about
> > no known host if you just try to create one that doesn't actually exist,
> > but two issues there:
>
> What's a bigger PITA for me is when a client we back up is retired and
> the DNS entry deleted without letting the humble backup admin know.  In
> addition to not being able to add a client with a bogus name, you also
> can't *delete* or *modify* a client with a bogus name.  Makes it a chore
> to delete a client from NetWorker after the DNS has already been updated.
>
> > 1. What about the fact that the 'Enabler in use' field will be 'No' and
> > the other fields like: 'NetWorker version', 'Client OS type:', etc. will
> > all be '<none>'. Will that matter for the fake client?
>
> It's never mattered so far, in my experience.
>
> > 2. If the savesets you want are still in the media database, then why
> > could you not instead just run run mminfo to get savesets and associated
> > ssids and then use recover command with -S option, specifying ssid
> > value(s), without even having to have the fake client at all with that
> > same name or client id?
>
> Where are you going to recover the data to?  Let's say you want to recover
> data from old client `fred' to the machine `barney'.  If you try this
> without creating a new-fred client entry, I think you'll get a
>
>         machine barney is not on remote access list for client new-fred
>
> error from NetWorker.  It could be that I just haven't been using the
> right options all these years, but my experience is that you need to
> create the client temporarily to grant remote access so you can restore
> the data.
>
> > I realize that you can't use saveset recover in the GUI unless you
> > create a client with that name because the savesets won't show up until
> > the client has been re-created, but maybe recover command would not
> > require client to exist or even care that client id did not match or
> > same limitation there, too?
>
> If not for the ``remote access list'', it's possible you could be correct.
> However, I think that foils things pretty completely.
>
> Tim
> --
> Tim Mooney                              mooney AT dogbert.cc.ndsu.NoDak DOT 
> edu
> Information Technology Services         (701) 231-1076 (Voice)
> Room 242-J6, IACC Building              (701) 231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> --
> 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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=